Резервное копирование: restic и syncthing

Введение

Имейте не менее трех копий данных как минимум на двух физических носителях разного типа, причем одну из них храните вне дома или офиса – вот суть стратегии резервирования 3-2-1. Проверяем:

• исходные данные на компьютере – есть,
• резерв на внешних жестких дисках Transcend и Silicon Power благодаря robocopy – есть (хотя тип физического носителя как бы тот же – HDD, ну да ладно),
• копия вне дома – нет!

Что касается ресурсов Samba, особенно подключенных как сетевые диски, то они уязвимы для вирусов-шифровальщиков точно так же, как и локальные файлы. Следовательно, хотя какие-то копии у меня были и на сервере, их можно не учитывать. Нужны отдельные протоколы, чтобы запускать резервное копирование в нужный мне момент, а еще необходимо обеспечить выполнение третьего условия.

Итак, как следует из заголовка, вырисовывается следующая схема: архивируем документы и т.п. restic'ом, Syncthing'ом отправляем на сервер всякие фото-видео, и им же забираем все на ноутбук, который хранится на конспиративной квартире.

Вы можете возразить, что вирус может завестись на сервере и зашифровать все там. На мой взгляд, такая ситуация крайне маловероятная и вирус должен быть по типу молдавского (или там индийского) из анекдота. Все-таки непосредственно на сервере никто в интернетах не сидит, да и межсетевые экраны вроде как работают (в роутере и операционной системе). Так что подхватить заразу под Windows, к сожалению, намного более реально, а вот обнаружить и каким-то образом взломать серверное ПО пока что из области фантастики.

Очень теоретически вместо Syncthing можно было бы попробовать какое-нибудь личное облако типа Nextcloud. Может быть, я когда-нибудь и разверну его у себя (или вот новый ownCloud Infinite Scale), но по-моему Syncthing решает немного другую, более подходящую в данном случае задачу. В частности благодаря направлениям синхронизации и версионированию, как я опишу позже. Да и кто потом будет резервировать этот самый …cloud?

Должен сознаться, что вопрос я начал прорабатывать еще с 2021 года, так что статья весьма задержалась (думаю, в данном случае лучше поздно, чем никогда). Тогда на домашнем сервере у меня еще стояла CentOS 7, а еще вы увидите скриншоты из довоенной эпохи. Хотя веб-интерфейс Syncthing с тех пор и не поменялся, оказалось, грядет версия 2.0 (но пока еще находится на стадии кандидата к релизу).

restic

Это такая современная, как они говорят, программа для бэкапа. Она формирует так называемый репозиторий, при этом сочетая полный бэкап с дедупликаций. Иными словами при архивировании создается снимок всей структуры файлов и каталогов, но за счет дедупликации в репозиторий записываются только новые и изменившиеся блоки. А в отличие от дифференциальных или инкрементальных бэкапов скорость восстановления данных с конкретных снимков ±одинакова. По сути принцип аналогичен работе файловых систем с технологией COW (copy-on-write) типа btrfs и ZFS. Да, и все это дело еще сжимается и шифруется. Как следствие, такая система не очень подходит для уже сжатых файлов, т.е. фото, видео и архивов как таковых.

Установка сервера бэкапа

Т.е. в моем случае на Oracle Linux. Я почему-то решил скомпилировать бинарник из исходников еще на CentOS, который впоследствии перенес в OL9. Для истории покажу, как было дело (вопреки обыкновению, под администратором с этим вашим sudo):

sudo yum install https://repo.ius.io/ius-release-el7.rpm
sudo yum install git224
sudo yum install golang
git clone https://github.com/restic/rest-server.git
cd rest-server
CGO_ENABLED=0 go build -o rest-server ./cmd/rest-server
sudo chown root:root rest-server
sudo mv rest-server /usr/local/sbin

Изначально требовался наш любимый EPEL, а еще понадобилось установить «новый» git (видимо из IUS как раз, поскольку на «старом» возникала ошибка) и Go для компиляции. Честно говоря, сейчас я бы просто взял готовый бинарник с GitHub проекта.

В любом случае следующим шагом пробросим порт (8000) в firewalld. Пример сервиса /etc/firewalld/services/rest-server.xml:

<?xml version="1.0" encoding="utf-8"?>
<service>
    <short>Rest Server</short>
    <description>
    	Rest Server is a high performance HTTP server that implements restic's REST backend API.
        It provides secure and efficient way to backup data remotely, using restic backup client
        via the rest: URL.
    </description>
    <port protocol="tcp" port="8000"/>
</service>

firewall-cmd --permanent --add-service=rest-server
firewall-cmd --reload

Мы – борг. Вы будете ассимилированы. Сопротивление бесполезно.

Внезапный Стартрек объясняется тем, что изначально я планировать работать с Borg. Но поскольку Windows-клиента до сих пор не существует, я остановился на аналогичной программе, имеющую «родной» exe-шник. Тем не менее, я все же частично ассимилировался, создав пользователя borg:

useradd borg

Создадим основную директорию (mkdir) или, как в моем случае, подтом btrfs для репозиториев и назначим соответствующего владельца:

btrfs subvolume create /mnt/lvmred/restic
chown borg:borg /mnt/lvmred/restic

Осталось определить сервис systemd. В исходниках есть пример (examples/systemd/rest-server.service), который я и скопировал в /usr/local/lib/systemd/system. Исправил User, Group, ExecStart и ReadWritePaths. На всякий случай привожу сервис целиком:

[Unit]
Description=Rest Server
After=syslog.target
After=network.target

# if you want to use socket activation, make sure to require the socket here
#Requires=rest-server.socket

[Service]
Type=simple
# You may prefer to use a different user or group on your system.
User=borg
Group=borg
ExecStart=/usr/local/sbin/rest-server --path /mnt/lvmred/restic --no-auth
Restart=always
RestartSec=5

# The following options are available (in systemd v247) to restrict the
# actions of the rest-server.

# As a whole, the purpose of these are to provide an additional layer of
# security by mitigating any unknown security vulnerabilities which may exist
# in rest-server or in the libraries, tools and operating system components
# which it relies upon.

# IMPORTANT!
# The following line must be customised to your individual requirements.
ReadWritePaths=/mnt/lvmred/restic

# Makes created files group-readable, but inaccessible by others
UMask=027

# If your system doesn't support all of the features below (e.g. because of
# the use of an older version of systemd), you may wish to comment-out
# some of the lines below as appropriate.
CapabilityBoundingSet=
LockPersonality=true
MemoryDenyWriteExecute=true
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=true
PrivateUsers=true
ProtectSystem=strict
ProtectHome=yes
ProtectClock=true
ProtectControlGroups=true
ProtectKernelLogs=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectProc=invisible
ProtectHostname=true
RemoveIPC=true
RestrictNamespaces=true
RestrictAddressFamilies=AF_INET AF_INET6
RestrictSUIDSGID=true
RestrictRealtime=true
SystemCallArchitectures=native
SystemCallFilter=@system-service

# Additionally, you may wish to use some of the systemd options documented in
# systemd.resource-control(5) to limit the CPU, memory, file-system I/O and
# network I/O that the rest-server is permitted to consume according to the
# individual requirements of your installation.
#CPUQuota=25%
#MemoryMax=bytes
#MemorySwapMax=bytes
#TasksMax=N
#IOReadBandwidthMax=device bytes
#IOWriteBandwidthMax=device bytes
#IOReadIOPSMax=device IOPS, IOWriteIOPSMax=device IOPS
#IPAccounting=true
#IPAddressAllow=

[Install]
WantedBy=multi-user.target

Аутентификацией в локальной сети бессовестным образом предлагаю пренебречь (параметр --no-auth в ExecStart). Поехали:

systemctl enable --now rest-server

В принципе сервер готов.

Бэкап-клиент (Windows)

Здесь без самодеятельности – скачал архив, распаковал, для определенности, в D:\BACKUP\restic и удалил лишнее из названия exe-шника. Инициализировал удаленный репозиторий по адресу http://192.168.1.2:8000/main/ (в командной строке):

restic -r rest:http://192.168.1.2:8000/main/ init
enter password for new repository:
enter password again:
created restic repository 2........5 at rest:http://192.168.1.2:8000/main/

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

Как видите, в обязательном порядке запрашивается пароль. Как тут не вспомнить unzip.zip…

Для бэкапа предлагаю создать файл backup.cmd, чтобы не вводить каждый раз относительно длинную команду, а также файл dirs.txt в кодировке UTF-8, в котором перечислим пути, которые требуется резервировать. Еще я предлагаю сразу же предусмотреть файл со списком исключений exclude.txt. К созданному командному файлу можно создать ярлык на рабочем столе, тогда рекомендую добавить команду pause, чтобы окно не закрылось по окончании работы.

Пример backup.cmd:

restic -r rest:http://192.168.1.2:8000/main/ -v backup --files-from-verbatim dirs.txt --exclude-file exclude.txt
pause

В качестве путей (dirs.txt) возьму две папки документов – одну из профиля пользователя (я их переношу из стандартного расположения типа C:\Users\…) и одну просто созданную вручную (в которой я и храню свои документы):

D:\profile\DOCS
E:\Мои документы

Что касается исключений (exclude.txt), для примера уберем настройки папок (desktop.ini), базы миниатюр, генерируемые проводником в Windows до версии 10, файлы блокировки документов LibreOffice, а также данные системы контроля версий git (имеет ли вообще смысл архивировать такие проекты – вопрос интересный, возможно все-таки имеет на тот случай, если «накроется» сам git или к примеру потребуется найти что-то «незакоммиченное», но при этом чудом попавшее в бэкап).

desktop.ini
Thumbs.db
.~lock.*#
.git

Стоит заметить, что в моем простейшем примере будет запрошен пароль для доступа к репозиторию (заданный на этапе инициализации). Проще всего в начале файла установить соответствующую переменную окружения, но вот является ли это безопасным – вопрос. По идее-то такая переменная «живет» только во время сеанса командной строки… Или сохранить пароль в файл и передавать этот файл в качестве параметра --password-file (чем лучше отдельный файл по сравнению с паролем прямо в скрипте, тоже не совсем понятно). Если совсем уж углубляться, то можно использовать команду ОС (программу), которая извлекла бы пароль из некоего защищенного хранилища, но это по-моему как-то совсем нетривиально.

SET RESTIC_PASSWORD=mainrepositorypassword

Кстати, раз уж мы заговорили о переменных окружения, путь к репозиторию можно поместить в переменную RESTIC_REPOSITORY и, таким образом, не указывать каждый раз параметр -r. Это может оказаться удобным, если в командном файле будет несколько этих самых команд.

В Windows можно (или даже нужно!) воспользоваться опцией --use-fs-snapshot, т. е. делать бэкап на основе «теневой копии», а не на «живых файлах». Все бы ничего, но создание теневых копий требует административных привилегий, так что придется сначала запускать командную строку от имени администратора, и только потом в ней уже запускать скрипт (команду) бэкапа. Либо модифицировать скрипт (добавить переход на нужный диск и смену директории), чтобы в свойствах ярлыка к нему можно было поставить запуск от имени администратора . Тем не менее, на все эти жертвы скорее всего стоит пойти, чтобы повысить вероятность формирования «правильного» бэкапа, а не какого-нибудь мусора вместо файлов.

SET RESTIC_PASSWORD=mainrepositorypassword
D:
cd \BACKUP\restic
restic -r rest:http://192.168.1.2:8000/main/ -v backup --use-fs-snapshot --files-from-verbatim dirs.txt --exclude-file exclude.txt
pause

Теперь возникает вопрос, как «в случае чего» (конечно же я желаю, чтобы этот самый случай никогда не наступил) восстановить данные. Для начала стоит получить список снимков командой snapshots (как я писал ранее, когда вы запускаете команду backup, создается так называемый снимок, что позволяет к примеру получать версию файла на нужную дату):

restic -r rest:http://192.168.1.2:8000/main/ snapshots

Теперь в дальнейших командах можно использовать ID снимка из полученной таблицы либо использовать зарезервированный ID latest для последнего из них. Командой ls можно вывести список файлов в снимке (хотя для больших репозиториев это наверное не самая хорошая идея, лучше воспользоваться командой find для поиска или задать фильтры, либо хотя бы перенаправить вывод в файл, что и продемонстрировано в примере).

restic -r rest:http://192.168.1.2:8000/main/ ls latest > ls.txt

Для восстановления файлов (извлечения из бэкапа) служит команда restore. Можно восстановить как снимок целиком, так и отдельные каталоги (опция --path) или файлы (опция --include).

Например восстановим весь последний снимок в подпапку main-latest (параметр --target):

restic -r rest:http://192.168.1.2:8000/main/ restore latest --target main-latest

Осталось, видимо, обсудить очистку репозитория от старых снимков (все-таки место на сервере не резиновое). Для этого нужно использовать пару команд forget и prune или одну команду forget с флагом --prune. В нашем случае скорее всего проще воспользоваться вторым вариантом. Можно удалить как конкретный снимок, так и в соответствии с правилами. Точнее правилами описываются те снимки, которые следует оставить.

Например можно оставить 7 последних снимков, 4 еженедельных архива и 6 ежемесячных. В принципе наверное можно еще один-два годовых добавить.

restic -r rest:http://192.168.1.2:8000/main/ forget --prune --keep-last 7 --keep-weekly 4 --keep-monthly 6 --keep-yearly 2

Подобную команду видимо тоже лучше сохранить в .cmd-файл (как вариант – следующей командой после архивирования). Конечно, существует масса нюансов в зависимости от того, как часто вы делаете бэкап (иными словами, расчет снимков, которые удовлетворяют указанным правилам), в которые мы наверное не будем углубляться. Скажу лишь, что наиболее очевидным образом команда отработает в случае ежедневных бэкапов (1 раз в день). В любом случае можно сначала выполнить команду с флагом --dry-run, чтобы просто вывести список оставляемых и удаляемых снимков.

Также опытным путем выяснилось, что имеет значение комбинация путей, т.е. в моем случае --keep-last 1 оставил фактически два снимка, поскольку я экспериментировал с различными наборами папок.

Syncthing

Хорошо, бэкап документов и прочей важной и конфиденциальной информации есть. Возникают вопросы – как резервировать «неважную» информацию типа фото и видео, а также делать бэкап бэкапа, т.е. репозиториев restic'а. На помощь спешит Syncthing – программа для непрерывной синхронизации файлов, как они сами про себя пишут.

Одной из особенностей программы является rsync-подобный алгоритм синхронизации файлов. Иными словами, для каждого файла вычисляются хэши (полный и частичные), что позволяет обновлять только изменившиеся блоки. Сетевой трафик, таким образом, экономится (а еще можно включить сжатие), но в случае больших файлов возникает проблема в виде долгого вычисления этих самых изменившихся фрагментов. В моем случае большими файлами являются диски виртуальных машин. С точки зрения синхронизации их целесообразно разбивать на части по 2 гигабайта, но тогда придется сразу выделить весь объем.

Сервер

На CentOS (а затем и OL9), в отличие от restic, я скачал бинарник под root.

cd ~
wget https://github.com/syncthing/syncthing/releases/download/v1.16.1/syncthing-linux-amd64-v1.16.1.tar.gz
tar xvf syncthing-linux-amd64*.tar.gz
cp syncthing-linux-amd64-*/syncthing  /usr/local/sbin/

Если что, wget и tar могут быть изначально не установлены, но они конечно же есть в пакетах. По традиции я всякие кастомные программы располагаю в /usr/local/sbin – он локальный и включен в PATH.

echo $PATH
/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin

Нам потребуется сервис systemd. Скопируем содержимое etc/linux-systemd/system из архива в /usr/local/lib/systemd/system и исправим путь в ExecStart (файл syncthing@.service).

[Unit]
Description=Syncthing – Open Source Continuous File Synchronization for %I
Documentation=man:syncthing(1)
After=network.target
StartLimitIntervalSec=60
StartLimitBurst=4

[Service]
User=%i
ExecStart=/usr/local/sbin/syncthing serve --no-browser --no-restart --logflags=0
Restart=on-failure
RestartSec=1
SuccessExitStatus=3 4
RestartForceExitStatus=3 4

# Hardening
ProtectSystem=full
PrivateTmp=true
SystemCallArchitectures=native
MemoryDenyWriteExecute=true
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

Запустим и остановим сервис (после собаки указываем ранее созданного пользователя borg) для формирования конфигурации по умолчанию:

systemctl start syncthing@borg
systemctl stop syncthing@borg

Как и для restic, создадим подтом btrfs (или возможно просто директорию) для синхронизации, назначим владельца:

btrfs subvolume create /mnt/lvmred/Sync
chown borg:borg /mnt/lvmred/Sync

Отредактируем конфигурацию, в нашем случае это /home/borg/.config/syncthing/config.xml (в актуальных версиях вместо .config может использоваться .local/state) – отключим релеи, NAT и глобальное обнаружение:

<globalAnnounceEnabled>false</globalAnnounceEnabled>
<relaysEnabled>false</relaysEnabled>
<natEnabled>false</natEnabled>

А также изменим путь по умолчанию для папок – атрибут path тега folder в секции <default>:

<folder id="" label="" path="/mnt/lvmred/Sync" type="sendreceive" rescanIntervalS="3600" fsWatcherEnabled="true" fsWatcherDelayS="10" ignorePerms="false" autoNormalize="true">

Наконец, разрешим удаленный доступ к веб-интерфейсу путем изменения адреса прослушивания на 0.0.0.0:

<gui enabled="true" tls="false" debugging="false">
        <address>0.0.0.0:8384</address>
        <!-- остальные настройки -->
</gui>

Теперь можно запустить сервис на постоянку и дальнейшую настройку вести через этот самый веб-интерфейс. Также не забываем про порты в firewalld – соответствующие сервисы уже предусмотрены:

systemctl enable --now syncthing@borg
firewall-cmd --permanent --add-service=syncthing
firewall-cmd --permanent --add-service=syncthing-gui
firewall-cmd --reload

На этом переходим в Windows.

Клиент – Windows

Скачиваем архив, распаковываем и запускаем программу. Открывается веб-интерфейс. Анонимный отчет об использовании скорее всего запрещаем.

GUI-аутентификация именно для localhost скорее всего тоже не нужна (а вот на сервере я в конечном счете ее настроил). По аналогии с сервером предлагаю отключить всякие глобальные обнаружения и иже с ними (Действия – Настройки, вкладка Подключения):

Заодно советую отключить обновления (в Linux программа сама себя обновить не может при моем подходе, проще везде синхронизировать версии вручную) на вкладке «Общие» и автоматический запуск браузера в настройках интерфейса (я предпочитаю сам его открывать при необходимости).

Добавляем новое удаленное устройство (по не слишком заметной кнопке на основном экране). Поскольку Syncthing на сервере уже запущен, то по идее его идентификатор должен появится в списке «устройств рядом»:

Теперь добавляем MAIN (компьютер) на сервер – открываем http://192.168.1.2:8384/ (где 192.168.1.2 – IP-адрес сервера). В принципе должен появиться запрос:

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

Для примера расшарил некую папку D:\Sync на главном компьютере. Добавляем ее (лучше указать «ярлык» сразу, иначе она будет отображаться под сгенерированным идентификатором) и сразу же предоставляем доступ SERVPC:

Вновь на сервере появляется запрос подтверждения:

Как видим, настройки пути по умолчанию применились, путь предложен внутри /mnt/lvmred/Sync:

Аналогичным образом добавляются реальные папки типа фоточек с видосиками. Хочу обратить внимание на возможность указания типа папки: Отправить и получить (sendreceive, по умолчанию), Только отправить (sendonly) и Только получить (receiveonly).

Это позволяет настраивать направление синхронизации, чем я интенсивно пользуюсь. Например, архив фотографий я «только отправляю», тем самым защищая фотки на компьютере от возможных изменений на сервере. Вообще-то в моем сценарии такого не должно происходить и будет свидетельствовать о ЧП! Кстати на сервере как раз можно еще и версионирование включить, и тогда в свою очередь появление нескольких версий будет говорить нам о проблемах.

Для удобства создал ярлык к Synthing в меню «Пуск» (т.е. в моем случае в C:\Users\Vetkhy\AppData\Roaming\Microsoft\Windows\Start Menu\Programs).

Копия вне дома – ноутбук

Небольшая историческая справка – сначала я купил винчестер Toshiba L200 на 2 TB для суперстарого ноутбука Toshiba Satellite и накатил туда CentOS, плюс еще и зашифровал все полностью (LUKS), чтоб мало не показалось. Разумеется, все работало, но крайне медленно. С появлением «большой восьмерки» я перекинул диск в Acer (заодно оперативку поменял), а установить решил Linux Mint (якобы чтобы можно было что-то на нем еще поделать). При этом было предложено воспользоваться шифрованием ZFS, почему бы и не да? Увы, хорошая мысля приходит опосля – надо было уж тогда FreeBSD внедрять…

Установка Syncthing, как и на сервере, заключается в распаковке архива и перемещении исполняемого файла в /usr/local/sbin. Права 755 должны извлечься из архива, а пользователя скорее всего надо будет поменять на root.

Но прежде чем переходить к настройке, воспользуемся возможностями ZFS и создадим несколько файловых систем (здесь это некий аналог подтомов btrfs) или датасетов, если угодно. Установщик понасоздавал два пула (загрузочный и корневой), а на корневом еще и кучу этих самых ФС. Домашнему каталогу соответствовала rpool/USERDATA/acer_rl2mhr, казалось бы надо создать rpool/USERDATA/acer_rl2mhr/syncthing, но нет – в этом случае датасет воспринимается системой как съемный диск (removable device), что раздражает.

Поэтому я бессовестным образом создал rpool/USERDATA/syncthing – вновь в порядке исключения работаю под администратором (пользователь acer в данном случае):

sudo zfs create rpool/USERDATA/syncthing

Файловая система монтируется на /syncthing – меня устраивает. Далее создал специализированные датасеты для виртуальных машин и репозиториев restic:

sudo zfs create rpool/USERDATA/syncthing/VM
sudo zfs create rpool/USERDATA/syncthing/restic
sudo chown -R acer:acer /syncthing

Не забываем про владельца. Теперь я хочу похимичить с компрессией. По умолчанию это lz4, но для большей части архивных данных она бесполезна. Поэтому у всего syncthing пусть будет Злотеус zle (сжатие последовательностей нулевых байтов), а lz4 у виртуальных машин.

sudo zfs set compression=zle rpool/USERDATA/syncthing
sudo zfs set compression=lz4 rpool/USERDATA/syncthing/VM

На ноутбуке, как и на основном компьютере, я запускаю syncthing вручную. Настройка в общем тоже аналогична компьютеру, только всем папкам я назначаю тип receiveonly и пути прописываю с учетом созданной структуры ZFS.

Несмотря на то, что Acer явно быстрее Toshiba, ZFS с шифрованием все равно производительность съедает. Скорость синхронизации конечно быстрее 100 мегабит, но и до гигабита ей далеко. Так что старого доброго 802.11n вполне хватает и можно не заморачиваться с кабелем.

В «Дополнительных» настройках можно (или даже скорее нужно) ограничить конкуренцию «интенсивных» операций ввода-вывода (сканирование, синхронизация) до 1 потока (maxFolderConcurrency).

Большее количество потоков ноутбучный диск, да еще и зашифрованный, по сути не потянет.

Проверка репозиториев с использованием клона датасета

Напоследок я хочу показать вам, как можно проверить репозитории restic'а. Благодаря ZFS предлагаю делать это на клоне файловой системы, чтобы не влиять на Syncthing (на тот случай, если вдруг последуют какие-то изменения в процессе).

Сначала нужно сделать снимок датасета и только потом его клонировать:

sudo zfs snapshot rpool/USERDATA/syncthing/restic@s1
sudo zfs clone rpool/USERDATA/syncthing/restic@s1 rpool/USERDATA/syncthing/restic-check

Сам restic в случае Linux Mint (а скорее всего Ubuntu на самом деле) есть в пакетах, так что устанавливаем:

sudo apt install restic

И «натравляем» restic на нужный репозиторий одной из команд:

restic -r /syncthing/restic-check/main check
restic -r /syncthing/restic-check/main check --read-data

Флаг --read-data включает проверку самих данных в репозитории, а не только его структуры. Аналогично можно проверить репозиторий на сервере с компьютера, разве что особой необходимости в манипуляциях с подтомами нет.

После успешного (я надеюсь) выполнения команды удалим клон и снимок:

sudo zfs destroy rpool/USERDATA/syncthing/restic-check
sudo zfs destroy rpool/USERDATA/syncthing/restic@s1

Чуть не забыл, мы же еще можем проверить целостность данных пула ZFS как такового:

sudo zpool scrub rpool
zpool status -v rpool

Первая команда запускает проверку, а второй можно посмотреть состояние.

Вместо заключения

Поскольку разработчики Syncthing мамой клянутся, что передача данных зашифрована, можно было бы включить глобальное обнаружение, пробросить основные порты (22000 TCP и UDP, 21027 UDP) в роутере к серверу и синхронизироваться через интернет. Проблем примерно две – на конспиративной квартире нет стационарного интернета (а мобильный безлимит канул в лету) и весь процесс весьма длительный. Так что я пользуюсь HDDNet, т.е. периодически привожу ноутбук домой, делаю все дела и отвожу обратно.

С другой стороны, поскольку репозитории restic'а тоже зашифрованы, их можно было бы отправлять в какое-нибудь облако rclone'ом. Проблема найти такое облако, чтобы можно было хранить хотя бы терабайт и при этом не разориться. Определенные надежды я в свое время связывал с мегафоновским, но его закрыли. В рамках экспериментов я пробовал и Backblaze B2 (которое S3), но думаю можно смело говорить о том, что и этот вариант отправился вслед за облаком от Мегафона. Китайские? Ну, эээ…