Жёсткий диск умирает тихо. Иногда он скрипит за неделю до конца, иногда просто не запускается утром в среду, и фотографии последних восьми лет превращаются в строчку из вывода dmesg. Папка "Бэкап", куда раз в полгода копируется домашний каталог, тут не спасает, потому что она лежит на том же диске. И даже если её вовремя перетащили на внешний накопитель, остаётся вопрос версий, шифрования и последовательности действий, когда квартиру зальёт, а ноутбук украдут. BorgBackup закрывает эту дыру целиком, и закрывает её довольно красиво.
Чем простое копирование папок принципиально отличается от настоящего резервного копирования
Если коротко, всем. Когда человек делает обычный рекурсивный копир, он получает один слепок текущего состояния:
cp -r ~/Documents /mnt/backup/documents-$(date +%Y%m%d)
Изменил один байт в файле на 4 гигабайта - скопировал заново и потратил место. Удалил файл по ошибке три недели назад, заметил вчера, и его уже нет ни в текущем виде, ни в архиве, потому что архив один и он перетёрт. Зашифровать всё это можно только дополнительной обёрткой, и любая такая обёртка означает либо ручную работу, либо новую точку отказа.
Настоящий бэкап решает три задачи одновременно. Хранит много версий и не разрастается до бесконечности. Защищает данные от того, кто получит доступ к самому хранилищу. Восстанавливается быстро и предсказуемо. Borg делает ровно это, причём через одну консольную утилиту, написанную в основном на Python и C, с расчётом на ежедневное использование. На сайте проекта это формулируется ёмко - дедуплицирующий архиватор со сжатием и аутентифицированным шифрованием.
Как Borg экономит десятки гигабайт за счёт content-defined chunking и переменных чанков
Главная инженерная идея внутри Borg называется content-defined chunking. Файл не режется на куски фиксированного размера, как делают многие архиваторы. Вместо этого скользящее окно ищет границы по содержимому, и каждый кусок получает криптографический хеш. Если такой кусок уже лежит в репозитории, он не записывается повторно, а просто упоминается ссылкой. Звучит как академический трюк, но на практике это та самая магия, из-за которой ежедневные архивы домашней папки занимают копейки.
Допустим, есть видеопроект на 20 гигабайт. В пятницу автор подвинул в нём пару клипов и пересохранил. Классический архиватор увидит файл с другим временем изменения и отправит на хранение все 20 гигабайт. Borg же разрежет файл на чанки, поймёт, что 19,8 гигабайта уже есть в хранилище, и допишет только реально изменившиеся фрагменты. После запуска borg create со статистикой сам инструмент показывает картину наглядно:
------------------------------------------------------------------------------
Original size Compressed size Deduplicated size
This archive: 6.85 MB 6.85 MB 30.79 kB
All archives: 13.69 MB 13.71 MB 6.88 MB
Unique chunks Total chunks
Chunk index: 167 330
------------------------------------------------------------------------------
Колонка Deduplicated size в 30 килобайт против 6,85 мегабайт оригинала - это не опечатка, а реальное поведение на втором запуске. Выгода становится особенно заметной не на первом запуске, а на десятом, сотом, трёхсотом.
Поверх дедупликации работает компрессия. Доступны lz4 для скорости, zstd для разумного баланса, zlib и lzma для тех случаев, когда место важнее процессора. Для домашних бэкапов zstd на средних настройках обычно даёт лучшее соотношение из всех вариантов:
borg create --compression zstd,3 \
/mnt/backup/borg-repo::laptop-{now} \
~/Documents ~/Pictures ~/Projects
Цифра после zstd задаёт уровень от 1 до 22, где 3 это разумный компромисс по скорости. Для архивов, которые давно не трогаются, можно поднять до 9 или 10 без особой потери в производительности.
Почему клиентское шифрование AES-OCB и chacha20-poly1305 меняет правила игры
Шифрование в Borg происходит до того, как данные покинули машину. Это принципиальный момент. Сервер, на котором хранится репозиторий, видит только зашифрованные чанки и не знает ни их содержимого, ни даже структуры файловой системы исходной машины. В свежей второй версии используются современные authenticated encryption схемы AES-OCB и chacha20-poly1305 с 256-битными ключами, обеспечивающие конфиденциальность, целостность и аутентичность одновременно.
Дополнительная опция обфускации умеет маскировать реальные размеры чанков, чтобы посторонний наблюдатель не мог по объёму трафика догадаться, какие именно файлы выгружаются. Для большинства домашних сценариев это избыточно, но для пользователей, которые гонят бэкапы через сторонние сервера и беспокоятся о профилировании, опция бесценна.
При создании репозитория стоит выбирать режим repokey-blake2:
# Создание репозитория с шифрованием
borg init --encryption=repokey-blake2 /mnt/backup/borg-repo
# Альтернативные режимы для понимания
borg init --encryption=repokey /mnt/backup/borg-repo # AES-CTR + HMAC
borg init --encryption=keyfile /mnt/backup/borg-repo # ключ отдельно
borg init --encryption=none /mnt/backup/borg-repo # без шифрования
Режим repokey-blake2 хранит ключ шифрования внутри самого репозитория, защищённый парольной фразой. Это удобно, пока есть надёжный способ хранить сам пароль. Менеджер паролей подходит идеально, главное помнить простое правило, о котором почему-то забывают абсолютно все новички. Бэкап менеджера паролей не должен лежать только внутри зашифрованного репозитория, потому что для расшифровки понадобится тот самый менеджер паролей. Получается замкнутый круг.
Резервная копия ключа делается одной командой и хранится отдельно от самого репозитория:
# Экспорт ключа в текстовый файл
borg key export /mnt/backup/borg-repo ~/borg-key-backup.txt
# Экспорт в формате для печати на бумаге
borg key export --paper /mnt/backup/borg-repo ~/borg-key-paper.txt
Флаг --paper форматирует ключ так, чтобы его можно было напечатать на принтере и положить в сейф. Идея кажется параноидальной ровно до того момента, как кто-то теряет пароль и понимает, что 800 гигабайт зашифрованных архивов превратились в дорогой генератор случайных чисел.
Установка и инициализация репозитория за пять минут на разных операционных системах
Установка элементарна и зависит только от пакетного менеджера:
# Debian / Ubuntu
sudo apt install borgbackup
# Fedora / RHEL
sudo dnf install borgbackup
# Arch Linux
sudo pacman -S borg
# macOS через Homebrew
brew install borgbackup
# Универсальный вариант через pip
pip install --user borgbackup
Существуют также самодостаточные бинарники с сайта проекта, не требующие никаких зависимостей кроме glibc, что удобно для серверов с минималистичной разметкой:
# Скачивание готового бинарника
wget https://github.com/borgbackup/borg/releases/download/1.4.0/borg-linux64
chmod +x borg-linux64
sudo mv borg-linux64 /usr/local/bin/borg
# Проверка версии
borg --version
После установки настраивается переменная окружения с путём к репозиторию и парольной фразой. Это избавляет от необходимости каждый раз вводить пароль и указывать путь:
# Добавить в ~/.bashrc или ~/.zshrc
export BORG_REPO="/mnt/backup/borg-repo"
export BORG_PASSPHRASE="ваша-длинная-парольная-фраза-минимум-30-символов"
# Применить изменения
source ~/.bashrc
Теперь команда borg init создаёт пустой репозиторий, готовый к приёму архивов:
borg init --encryption=repokey-blake2
Первый пробный архив проверяет, что вся машинерия работает:
borg create --stats --progress \
::test-{now} \
~/Documents
После пробного запуска стоит выполнить ту же команду повторно, изменив одну строчку в одном файле. Разница между размером оригинала и тем, что реально дописалось в репозиторий, как правило, заставляет улыбнуться даже скептиков.
Грамотный выбор того, что бэкапить, и игнорирование лишнего мусора
Бэкапить домашнюю папку целиком соблазнительно, но почти всегда неправильно. Кеш браузера, node_modules, образы виртуальных машин, выгруженные торренты и временные файлы Docker съедают место и время совершенно бесполезно. Вместо этого описывается список исключений, и Borg сам пропустит ненужное:
# Файл /etc/borg/exclude.list
*/.cache/*
*/node_modules/*
*/.npm/*
*/__pycache__/*
*/venv/*
*/.venv/*
*/target/*
*/build/*
*/dist/*
*/.tox/*
*/.gradle/*
*.pyc
*.pyo
*.swp
*.swo
*~
*/Trash/*
*/.local/share/Trash/*
*/Downloads/torrents/*
*/VirtualBox\ VMs/*
*/Library/Caches/*
*/.thumbnails/*
*/.mozilla/firefox/*/Cache/*
*/.config/google-chrome/*/Cache/*
Этот файл подключается к команде создания архива одним флагом:
borg create \
--exclude-from /etc/borg/exclude.list \
--exclude-caches \
--one-file-system \
--compression zstd,3 \
--stats \
::laptop-{hostname}-{now:%Y-%m-%d-%H%M%S} \
~/Documents \
~/Pictures \
~/Projects \
~/.config \
~/.ssh \
~/.gnupg
Флаг --exclude-caches пропускает все каталоги, помеченные стандартным маркером CACHEDIR.TAG, который умеют ставить большинство современных приложений. Флаг --one-file-system удерживает Borg от случайного захода в смонтированные сетевые папки, что когда-то спасло автору этих строк целый ночной запуск, ушедший было гулять по NFS-шаре с фильмами.
Автоматизация ежедневных бэкапов через systemd timer и грамотный prune
Запускать команды руками каждый вечер не будет никто. Поэтому следующий шаг превращает Borg в фоновую службу, которая работает сама. Классический путь через cron работает, но systemd timer надёжнее для современных дистрибутивов, потому что умеет догонять пропущенные запуски, ведёт чистые логи через journalctl и не падает молча, если ноутбук был выключен в нужный час.
Сначала пишется единый скрипт-обёртка, который делает всю работу:
#!/bin/bash
# /usr/local/bin/borg-backup.sh
set -euo pipefail
export BORG_REPO="/mnt/backup/borg-repo"
export BORG_PASSPHRASE="$(cat /root/.borg-passphrase)"
# Логирование в журнал systemd
exec > >(systemd-cat -t borg-backup -p info) 2>&1
echo "Начало бэкапа $(date)"
# Создание архива
borg create \
--verbose \
--filter AME \
--list \
--stats \
--show-rc \
--compression zstd,3 \
--exclude-from /etc/borg/exclude.list \
--exclude-caches \
::'{hostname}-{now:%Y-%m-%d-%H%M%S}' \
/home \
/etc \
/var/log \
/var/lib/docker/volumes
backup_exit=$?
# Чистка старых архивов по политике хранения
borg prune \
--list \
--glob-archives '{hostname}-*' \
--show-rc \
--keep-daily 7 \
--keep-weekly 4 \
--keep-monthly 6 \
--keep-yearly 2
prune_exit=$?
# Освобождение места на диске после prune
borg compact
compact_exit=$?
# Итоговый код возврата
global_exit=$(( backup_exit > prune_exit ? backup_exit : prune_exit ))
global_exit=$(( global_exit > compact_exit ? global_exit : compact_exit ))
if [ ${global_exit} -eq 0 ]; then
echo "Бэкап завершён успешно"
elif [ ${global_exit} -eq 1 ]; then
echo "Бэкап завершён с предупреждениями"
else
echo "Бэкап завершён с ошибками"
fi
exit ${global_exit}
Файл с парольной фразой должен быть доступен только root и содержать одну строку:
echo "ваша-парольная-фраза" | sudo tee /root/.borg-passphrase
sudo chmod 600 /root/.borg-passphrase
Дальше создаются два юнита для systemd. Первый описывает саму службу, второй её расписание:
# /etc/systemd/system/borg-backup.service
[Unit]
Description=BorgBackup ежедневный бэкап
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/borg-backup.sh
Nice=19
IOSchedulingClass=best-effort
IOSchedulingPriority=7
[Install]
WantedBy=multi-user.target
# /etc/systemd/system/borg-backup.timer
[Unit]
Description=Запуск BorgBackup каждый день в 3 ночи
Requires=borg-backup.service
[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=30min
Persistent=true
[Install]
WantedBy=timers.target
Параметр Persistent=true заставляет systemd запустить пропущенный таймер сразу после загрузки, если машина была выключена в назначенное время. Это критично именно для ноутбуков, где выключение в три ночи скорее норма, чем исключение. RandomizedDelaySec размазывает запуски по получасу, что полезно, если несколько машин пишут в одно сетевое хранилище.
Активация всей конструкции:
sudo systemctl daemon-reload
sudo systemctl enable --now borg-backup.timer
# Проверка расписания
systemctl list-timers borg-backup.timer
# Просмотр логов
journalctl -t borg-backup -f
Стандартная политика хранения, заданная в скрипте, выглядит примерно так. Семь ежедневных архивов, четыре еженедельных, шесть ежемесячных и пара годовых. Это даёт глубину истории на два года при разумной плотности на свежих неделях, где ошибки замечаются чаще всего. Для разных задач политика подбирается индивидуально, но эта схема работает в большинстве домашних сценариев.
Использование borgmatic как удобной обёртки над всеми командами разом
Для тех, кто не любит писать bash-скрипты руками, существует обёртка borgmatic. Она читает YAML-файл с конфигурацией, сама вызывает borg create, prune, compact и check в нужном порядке, отправляет уведомления в healthchecks.io, ntfy или на почту, и устраняет половину ошибок невнимательности, которые случаются при ручной настройке.
Установка и инициализация:
sudo apt install borgmatic
# или
pip install --user borgmatic
# Создание шаблона конфигурации
borgmatic config generate --destination /etc/borgmatic/config.yaml
Минимальный рабочий конфиг выглядит понятно даже для тех, кто никогда не видел YAML:
# /etc/borgmatic/config.yaml
source_directories:
- /home
- /etc
- /var/log
repositories:
- path: /mnt/backup/borg-repo
label: local
- path: ssh://[email protected]/./repo
label: remote
exclude_patterns:
- '*/.cache'
- '*/node_modules'
- '*/__pycache__'
- '*.pyc'
exclude_caches: true
exclude_if_present:
- .nobackup
encryption_passcommand: cat /root/.borg-passphrase
compression: zstd,3
archive_name_format: '{hostname}-{now:%Y-%m-%d-%H%M%S}'
keep_daily: 7
keep_weekly: 4
keep_monthly: 6
keep_yearly: 2
checks:
- name: repository
frequency: 1 week
- name: archives
frequency: 1 month
healthchecks:
ping_url: https://hc-ping.com/your-uuid-here
send_logs: true
Запуск всего цикла одной командой:
# Создать архив, выполнить prune и проверки
borgmatic --verbosity 1
# Только создать архив без prune
borgmatic create --verbosity 1
# Посмотреть список архивов
borgmatic list
# Извлечь конкретный файл
borgmatic extract --archive latest --path home/user/Documents/important.pdf
Для домашнего парка из ноутбука, стационара и медиасервера borgmatic превращает бэкапы в почти невидимый процесс. Ping_url отправляет сигнал в healthchecks.io после каждого успешного запуска, и сервис присылает уведомление, если сигнал не пришёл в ожидаемое время. То есть про сломавшийся бэкап вы узнаёте не через полгода в момент паники, а на следующее утро спокойно за чашкой кофе.
Отправка зашифрованного репозитория в облачное S3-хранилище через rclone
Локальный бэкап на внешний диск спасает от поломки железа, но не от пожара, кражи всей квартиры или зашифровавшего систему вымогателя, добравшегося до подключённой USB-флешки. Поэтому к локальной копии добавляется удалённая, и тут начинается самое интересное. Borg умеет работать через SSH с любым сервером, где он установлен, что покрывает варианты с собственным VPS, Hetzner Storage Box или специализированным сервисом BorgBase. Но если сервера своего нет, а платить хочется только за реально занятое место, на сцену выходит rclone.
Rclone это утилита, которая говорит на языке более чем 70 облачных хранилищ. Amazon S3, Backblaze B2, Wasabi, Cloudflare R2, Google Drive, OpenStack Swift, Microsoft Azure, обычный SFTP, и так далее. Схема работы простая. Borg пишет архив в локальную папку, а rclone синхронизирует эту папку с облачным бакетом. В результате в облако улетает уже зашифрованный репозиторий, и провайдер хранилища при всём желании не сможет ничего из него прочитать.
Установка rclone:
# Универсальный установщик с официального сайта
curl https://rclone.org/install.sh | sudo bash
# Или через пакетный менеджер
sudo apt install rclone
# Проверка
rclone version
Настройка интерактивная, занимает примерно три минуты:
rclone config
После выбора New remote, имени и типа хранилища (например b2 для Backblaze), мастер запросит ключи доступа. Конфиг при этом создаётся автоматически и выглядит примерно так:
# ~/.config/rclone/rclone.conf
[b2-backup]
type = b2
account = 003abc1234567890abcdef
key = K003xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
hard_delete = false
[wasabi-backup]
type = s3
provider = Wasabi
access_key_id = WASABIXXXXXXXXXXXXXX
secret_access_key = wasabixxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
endpoint = s3.eu-central-1.wasabisys.com
region = eu-central-1
Backblaze B2 здесь стал почти народным выбором благодаря ценам в районе 0,6 цента за гигабайт в месяц и щедрому бесплатному исходящему трафику через альянс с Cloudflare. Wasabi берёт фиксированную ставку без платы за исходящий трафик, что удобно, если нужно регулярно вытаскивать большие объёмы. Cloudflare R2 идёт следом по соотношению цены и скорости, плюс не берёт плату за egress совсем.
Скрипт синхронизации запускается после успешного завершения borg create:
#!/bin/bash
# /usr/local/bin/borg-cloud-sync.sh
set -euo pipefail
REPO_PATH="/mnt/backup/borg-repo"
REMOTE="b2-backup:my-borg-bucket"
LOG_FILE="/var/log/borg-cloud-sync.log"
rclone sync "${REPO_PATH}" "${REMOTE}" \
--transfers 16 \
--checkers 32 \
--fast-list \
--progress \
--log-file "${LOG_FILE}" \
--log-level INFO \
--bwlimit "08:00,2M 23:00,off" \
--b2-hard-delete=false
Параметр --transfers 16 для B2 имеет особый смысл. Документация Backblaze прямо говорит, что значение по умолчанию в 4 потока для их хранилища занижено, и оптимум для среднего домашнего канала находится в районе 16-32 параллельных передач. Параметр --bwlimit задаёт ограничение скорости в дневное время, чтобы бэкап не занимал весь канал, пока в той же квартире кто-то смотрит видео в высоком разрешении.
Полный скрипт с локальным бэкапом и последующей выгрузкой в облако:
#!/bin/bash
# /usr/local/bin/borg-full-cycle.sh
set -euo pipefail
# Шаг 1. Локальный бэкап
/usr/local/bin/borg-backup.sh
local_exit=$?
# Шаг 2. Синхронизация в облако только при успешном локальном бэкапе
if [ ${local_exit} -le 1 ]; then
/usr/local/bin/borg-cloud-sync.sh
sync_exit=$?
else
echo "Локальный бэкап провалился, синхронизация отменена"
exit ${local_exit}
fi
exit ${sync_exit}
Свежие беты Borg 2.0 пошли ещё дальше и научились обращаться к rclone напрямую через URL вида rclone://, что убирает промежуточный шаг с локальной синхронизацией:
# Возможный синтаксис в Borg 2.0 (бета)
borg create rclone://b2-backup/my-bucket::archive-{now} ~/Documents
Бета, правда, остаётся бетой, и для боевых данных пока разумнее использовать стабильную ветку 1.4 со связкой rclone sync. Разработчики прямо предупреждают, что между бета-релизами возможны несовместимые изменения, и репозитории придётся пересоздавать.
Проверка целостности и реальное восстановление как обязательный ритуал
Нетестированный бэкап равен отсутствующему бэкапу, и это не журналистская гипербола, а холодный практический факт. Архив может десять лет копироваться идеально и провалиться ровно в тот момент, когда понадобился. Поэтому раз в неделю стоит выполнять проверку целостности:
# Быстрая проверка структуры репозитория
borg check --verify-data /mnt/backup/borg-repo
# Проверка только конкретного архива
borg check --verify-data /mnt/backup/borg-repo::laptop-2026-04-15
# Проверка с ограничением по времени, чтобы не нагружать диск
borg check --verify-data --max-duration 3600 /mnt/backup/borg-repo
Команда пересчитывает хеши всех чанков и ловит битый сектор задолго до того, как он превратится в проблему. Раз в месяц полезно действительно достать какой-нибудь файл из недельной давности архива и сравнить его с оригиналом. Команд для этого несколько:
# Список всех архивов в репозитории
borg list /mnt/backup/borg-repo
# Содержимое конкретного архива
borg list /mnt/backup/borg-repo::laptop-2026-04-15 | head -20
# Извлечение одного файла
cd /tmp/restore
borg extract /mnt/backup/borg-repo::laptop-2026-04-15 \
home/user/Documents/important.pdf
# Извлечение целой папки
borg extract /mnt/backup/borg-repo::laptop-2026-04-15 \
home/user/Pictures/
# Извлечение всего архива (осторожно с местом)
borg extract /mnt/backup/borg-repo::laptop-2026-04-15
Гораздо удобнее монтировать архив как обычную файловую систему через FUSE и работать с ним стандартным файловым менеджером:
# Создать точку монтирования
mkdir /tmp/borg-mount
# Смонтировать конкретный архив
borg mount /mnt/backup/borg-repo::laptop-2026-04-15 /tmp/borg-mount
# Или сразу весь репозиторий, тогда каждый архив будет отдельной папкой
borg mount /mnt/backup/borg-repo /tmp/borg-mount
# Теперь можно ходить туда любым проводником
ls /tmp/borg-mount/
# Размонтировать
borg umount /tmp/borg-mount
Восстановление целиком после катастрофы выглядит так. Ставится Borg на новую машину. Импортируется ключ из той самой отдельной копии. Подключается репозиторий, локальный или облачный через rclone. Выполняется borg extract, и через несколько часов рабочая среда возвращается на место:
# На свежей машине после установки Borg
export BORG_REPO="/mnt/recovery/borg-repo"
# Подгрузить репозиторий из облака
rclone sync b2-backup:my-borg-bucket /mnt/recovery/borg-repo
# Импортировать ключ из бумажной или электронной копии
borg key import /mnt/recovery/borg-repo ~/borg-key-backup.txt
# Найти нужный архив по дате
borg list
# Восстановить домашнюю папку из последнего архива
cd /
borg extract ::laptop-2026-04-15 home/user/
Никакой ручной расшифровки, никакого восстановления цепочки инкрементальных архивов через десять последовательных команд. Один extract и работа сделана.
Подводные камни, типичные ошибки и неочевидные нюансы при долгой эксплуатации
Несколько вещей выясняются обычно через полгода-год использования, и хорошо, когда выясняются они на учебных тестах, а не в день, когда диск умер.
Первое. Репозиторий не любит, когда к нему обращаются параллельно с двух машин под одним пользователем, и старая версия Borg могла оставить блокировку после аварийного завершения. Лечится одной командой:
borg break-lock /mnt/backup/borg-repo
Вторая ветка эту проблему почти убрала за счёт поддержки параллельных операций от одного клиента, но привычка проверять состояние не помешает.
Второе. После многократного prune репозиторий накапливает фрагментацию, и команда compact один раз в неделю освобождает реально занятое на диске место:
# Без этой команды репозиторий растёт даже при стабильном объёме данных
borg compact /mnt/backup/borg-repo
# С подробным выводом
borg compact --verbose /mnt/backup/borg-repo
Третье. Облачный rclone sync синхронизирует состояние, но не хранит историю изменений самого репозитория. Если местный бэкап повредится и эта порча уедет в облако, восстановиться будет неоткуда. Лекарство простое и красивое - включить версионирование в самом облачном бакете. У Backblaze B2 это дефолтное поведение, у S3 настраивается одной командой через aws cli или соответствующим флагом в консоли провайдера. Тогда даже катастрофа на локальной стороне не убивает удалённую историю.
Четвёртое. Не стоит забывать про мониторинг. Минимальная схема выглядит так:
# Добавить в конец скрипта бэкапа
if [ ${global_exit} -eq 0 ]; then
curl -fsS --retry 3 https://hc-ping.com/your-uuid-here > /dev/null
else
curl -fsS --retry 3 https://hc-ping.com/your-uuid-here/fail > /dev/null
fi
Healthchecks.io бесплатен для двадцати проверок и присылает уведомление, если ожидаемый пинг не пришёл в положенное время. Альтернативы вроде ntfy.sh работают по той же логике, только через webhook-уведомления на телефон.
Пятое и самое важное. Парольная фраза от репозитория и резервная копия ключа должны лежать минимум в двух физически разных местах. Бумажный листок в сейфе у родителей плюс зашифрованный файл в облачной заметке стороннего сервиса спасают значительно лучше, чем кажется до первой реальной аварии.
Полезные команды на каждый день для работы с уже настроенным репозиторием
Набор команд, которыми пользуешься чаще всего после того, как всё запущено и забыто:
# Информация о репозитории, его размере и шифровании
borg info /mnt/backup/borg-repo
# Информация о конкретном архиве
borg info /mnt/backup/borg-repo::laptop-2026-04-15
# Найти, в каких архивах есть конкретный файл
borg list /mnt/backup/borg-repo --pattern '+ *important.pdf'
# Сравнить два архива и увидеть, что изменилось
borg diff /mnt/backup/borg-repo::laptop-2026-04-14 \
/mnt/backup/borg-repo::laptop-2026-04-15
# Переименовать архив
borg rename /mnt/backup/borg-repo::old-name new-name
# Удалить конкретный архив
borg delete /mnt/backup/borg-repo::test-archive
# Сменить парольную фразу без пересоздания репозитория
borg key change-passphrase /mnt/backup/borg-repo
# Бенчмарк скорости работы
borg benchmark crud /mnt/backup/borg-repo /tmp/test-data
Команда borg diff особенно полезна при отладке, потому что показывает, какие именно файлы изменились между двумя соседними архивами, и иногда это раскрывает интересные вещи. Например, что какое-то приложение каждую ночь пересоздаёт огромный лог, или что синхронизатор Dropbox упорно тащит в бэкап один и тот же временный файл.
Что в итоге получает человек, прошедший весь путь настройки до конца
После того как все скрипты написаны, таймер взведён, облако подключено и тестовое восстановление прошло гладко, домашняя инфраструктура выходит на уровень, который десять лет назад был доступен разве что в больших компаниях с целым отделом сисадминов. Каждый вечер машина тихо отправляет инкрементальный зашифрованный архив на внешний диск. Каждое утро rclone дозаливает его в облачный бакет на другом континенте. История за два года занимает в разы меньше места, чем мог бы занять один полный слепок. Любой случайно удалённый файл достаётся за минуту командой borg extract. И самое главное, всё это работает само, без ежедневного внимания владельца.
Ради такого результата стоит провести один вечер с документацией, парой скриптов и менеджером паролей. Тем более что цена ошибки в обратном направлении становится понятной только после того, как однажды утром не запустился ноутбук, а в нём остались последние полгода жизни.
Канал сайта в Telegram
Канал сайта на YouTube