Btrfs и btrbk: лёгкий и быстрый инкрементальный бэкап сервера и домашнего ПК

Старая сисадминская пословица гласит: люди делятся на две категории — на тех, кто уже делает резервные копии, и тех, кто будет их делать.

Многие админы знакомы с этой ужасной сценой: 3 часа ночи, данные потеряны, и ты в панике, в холодном поту лихорадочно гуглишь, как спасти данные или ищешь телефон конторы по восстановлению дисков и ужасаешься их ценам. Избежать таких факапов помогает полезная привычка — вовремя и правильно делать бэкап.

В этой статье я покажу свой рабочий способ резервного копирования: файловая система Btrfs плюс утилита btrbk. Это самый лёгкий и быстрый инкрементальный бэкап и для сервера, и для домашнего ПК, который я знаю. Настройка занимает десять минут, ежедневный бакап — считанные минуты.

Btrfs + btrbk — это революция в мире бэкапа. Ещё никогда не было так просто и быстро создавать дифференциальные резервные копии. Никаких лицензий, подписок, платных программ — всё бесплатно и встроено в ядро Linux.

Как я делал инкрементальные бэкапы раньше

Много лет домашний каталог сервера с пользовательскими данными я бэкапил утилитой dar (Disk ARchive) французского разработчика Дени Корбена (Denis Corbin). Это две программы: архиватор dar, который создаёт полные и дифференциальные архивы, и dar_manager — менеджер каталогов архивов, который ведёт базу всех снимков и умеет восстанавливать файлы на нужную дату. Инструмент отличный: полные, дифференциальные и инкрементальные архивы, нарезка на тома нужного размера, выборочная архивация, сжатие разными алгоритмами, в том числе очень быстрым для распаковки zstd.

Но любой файловый архиватор работает на уровне файлов. dar честно сравнивает файл с архивированным по времени и размеру — если файл изменился, в дифференциальный архив он уходит целиком. На каталоге /home это означало:

• переименовал большую папку — она уезжает в архив заново, целиком;

• базы данных перебэкапивались заново всегда — стоило измениться хоть одному байту внутри файла БД, и многогигабайтный файл целиком попадал в «дифференциальную» копию;

• каждый прогон — это полный обход дерева всех каталогов: чтобы понять, что изменилось, dar обязан обойти все пользовательские каталоги и сверить stat() каждого файла с архивированными до этого — на миллионах файлов это десятки минут только на сканирование, ещё до того, как скопирован первый байт.

Полный обход дерева при каждом запуске — минус всех пофайловых бэкаперов без исключения: dar, rsync, tar, коммерческих программ. Ни одна из них не знает, что поменялось, пока не обойдёт всё дерево целиком.

В итоге «дифференциальный» бэкап на живых данных по объёму и времени мало отличался от полного. Это не проблема dar — это недостаток файлового подхода. Для ФС без поддержки снимков (ext4, XFS, FAT32, exFAT, NTFS и т. п.) dar + dar_manager до сих пор остаётся хорошим решением. Тем более что dar — кроссплатформенный (Linux, *nix, Windows).

После dar я довольно долго бэкапил /home программой rsync. Это прекрасная, заслуженная утилита, и плюсов у неё много: она есть в любом дистрибутиве и работает с любой файловой системой локально и через SSH, своим дельта-алгоритмом копирует только изменившуюся часть файла, умеет делать «снимки для бедных» на жёстких ссылках (--link-dest, как в rsnapshot, в бакапе это позволяет сослаться на файл из предыдущей копии без копирования), сохраняет права и сжимает на лету и т.д. и т.п. Но до скорости и удобства btrbk ей далеко:

• Нет атомарности. rsync копирует файлы по одному и идёт по дереву минутами, а то и часами. Пока обход идёт, файлы меняются — на выходе «размазанная» во времени копия, не соответствующая ни одному реальному состоянию системы. Чтобы копия была целостной, перед запуском приходится останавливать все активные процессы, которые пишут в /home (демоны, СУБД). Снимок Btrfs атомарен и мгновенен — останавливать почти ничего не нужно.

• Полный обход дерева. Та самая беда пофайлового подхода, о которой я писал выше про dar: rsync обязан stat() каждый файл, прежде чем поймёт, что копировать. На больших каталогах сканирование само по себе занимает десятки минут. btrbk не сканирует ничего.

• Переименование = повторное копирование. Передвинули или переименовали большой каталог — для rsync это «новые» файлы (в лучшем случае перелинковка через --link-dest, но всё равно с полным обходом). Btrfs передаёт несколько килобайт метаданных.

• Нет точной точки во времени. rsync синхронизирует «как успеется за время прохода», а btrbk фиксирует строгий срез на момент снимка.

Если файловая система умеет делать снимки, все эти минусы сразу исчезают: Btrfs работает не с файлами, а с блоками и деревом метаданных (об этом — ниже). Именно поэтому переход на Btrfs + btrbk я и называю революцией.

Был и третий сценарий — частный случай бакапа, обычно это про работу с большими файлами: на Btrfs их можно скопировать мгновенно через copy-on-write (cp --reflink). Копия создаётся за доли секунды и поначалу не занимает лишнего места. Тонкости и подводные камни этого режима я разбирал в отдельной статье — «Что не так с Copy-on-Write под Linux при копировании».

Когда я впервые забакапил с помощью Btrfs + btrbk огромную папку/home многопользовательского сервера — 1,5 ТБ данных всего за две минуты, я ощутил полный восторг и эйфорию. Это было похоже на чудо. Тот же дифференциальный бэкап этой папки через dar занимал у меня 6–8 часов. Шесть часов против двух минут! После такого обратно на файловый бакап не возвращаются.

Сколько копий нужно: правило 3-2-1

Есть проверенное временем правило 3-2-1. Его сформулировал фотограф Питер Крог (Peter Krogh) в книге «The DAM Book: Digital Asset Management for Photographers», а позже его подхватил американский US-CERT в публикации Data Backup Options.

• 3 копии данных,

• на 2 разных носителях,

• 1 из которых — вне помещения.

На практике: первая копия — на рабочей машине, вторая — на отдельном носителе, физически отключённом от неё, но в том же помещении (быстро восстановиться после «удалил не ту папку»), третья — на удалённой площадке (на случай пожара или кражи, когда первых двух уже нет). Btrfs и btrbk закрывают все три сценария одним инструментом.

Чем Btrfs принципиально лучше «обычного» инкрементального бэкапа

Классический инкрементальный бэкап (rsync, tar, большинство коммерческих агентов) работает на уровне файлов: он сравнивает, что изменилось, и копирует дельту. Звучит хорошо, пока не появляется большой диск.

Представьте корпоративное хранилище или сервер удалённых профилей: у каждого пользователя папка на несколько гигабайт. Пользователь переименовал каталог размером 100 ГБ. Для файлового бэкапа это 100 ГБ новых данных: по старому пути файлов больше нет, по новому — появились «новые». Вся дельта едет на бэкап заново.

Btrfs работает не с файлами, а с блоками и деревом метаданных. Переименование каталога — это изменение нескольких килобайт метаданных. При инкрементальной передаче между снимками Btrfs отправит ровно эти несколько килобайт, а не 100 ГБ. То же самое с перемещением, дедупликацией и copy-on-write копиями. Именно поэтому на больших и «живых» данных Btrfs-бэкап выигрывает у файлового на порядки.

Из-за этой простоты бэкапа и снимков я со временем перевёл на Btrfs вообще все свои разделы: на моих серверах на ней и /boot, и /, и /home. Btrfs уже давно в основном ядре Linux (с 2009 года), её дисковый формат стабилен и меняться не планирует, а ключевые вещи — снимки, send/receive, сжатие, контрольные суммы, RAID0/1/10 — помечены как стабильные. Единственное заметное исключение — встроенный RAID5/6, его в продакшене пока не используют. По умолчанию корень на Btrfs ставят openSUSE и SUSE Linux Enterprise (с 2014 года) и Fedora Workstation (с Fedora 33, 2020). А Meta (бывшая Facebook) держит на Btrfs миллионы серверов — все ОС и дата-тома. Всё это давно работает стабильно и чётко.

Снапшоты Btrfs: мгновенные и почти бесплатные

Снимок (снапшот) в Btrfs — это новый корень дерева подтома. Благодаря copy-on-write он не копирует данные: он фиксирует текущее состояние, а расходиться с оригиналом начинает только по мере изменений. Поэтому снимок создаётся мгновенно и почти не занимает места в момент создания.

Раз он мгновенный — его можно делать на лету, прямо на работающей системе, не останавливая сервисы. Но если есть выбор — делайте бэкап ночью. Что именно Btrfs при этом гарантирует, а что нет:

Практический вывод: для файлов и большинства сервисов хватает обычного снимка на лету. Для баз данных и демонов, которые активно пишут на ФС и держат состояние в своей памяти, перед снимком лучше:

• на мгновение приостановить базу данных или активно пишущий демон (многие СУБД умеют режим backup/freeze) — снимок мгновенный, так что пауза занимает доли секунды;

• либо снимать ночью, когда сервис простаивает.

Мой способ: каталог .snapshots и два скрипта

В корне каждой файловой системы я создаю каталог .snapshots и кладу туда два маленьких скрипта — создать снимок и удалить снимок. Намеренно держу их максимально простыми, без обвязки: их задача — делать именованные снимки с датой перед обновлением системы и сразу после него.

create_snapshot.sh — создать снимок с меткой времени и произвольным суффиксом:

#!/bin/bashbtrfs subvolume snapshot / @$(date +"%Y%m%d_%H:%M")_$1

del_snapshot.sh — удалить снимок по имени:

#!/bin/bashbtrfs subvolume delete $1

Запускаю их из каталога .snapshots, передавая первым аргументом осмысленный суффикс — короткую метку, по которой через месяц будет понятно, что это за снимок и зачем он создан (before_update, after_update, before_kernel, before_pg_upgrade). Снимок получает имя вида @20260515_10:30_before_update — дата, время и причина видны прямо в ls. Типичный сценарий вокруг апдейта:

cd /.snapshots./create_snapshot.sh before_updateemerge -uDN @world          # или apt full-upgrade / dnf upgrade./create_snapshot.sh after_update

Создание мгновенно, так что снимок «до» ничего не стоит, а снимок «после» фиксирует уже рабочую систему. Если обновление сломало загрузку — откат это не переустановка, а возврат на снимок before_update (как — в разделе про grub-btrfs ниже). Снимки, которые больше не нужны, убираю ./del_snapshot.sh @20260515_10:30_before_update.

Для тех, кто захочет развить идею: если планируете использовать снимок как опорную точку для btrfs send или для загрузки через grub-btrfs, добавьте в create_snapshot.sh флаг -r (read-only) — btrfs subvolume snapshot -r / .... Для ручного отката до/после апдейта это не обязательно: пишущий снимок тоже полностью рабочий.

Автоматизация и ротация: btrbk

Делать снимки руками перед апдейтами — хорошо, но настоящий бэкап должен быть автоматическим и сам управлять своим жизненным циклом. Эту роль берёт на себя btrbk — инструмент Акселя Бурри (Digital Integrity GmbH). О нём я узнал от разработчиков Calculate Linux в их телеграм-чате поддержки — за наводку им отдельное спасибо. btrbk написан на Perl — это один скрипт без зависимостей, поэтому легко ставится даже там, где его нет в репозитории дистрибутива; его описывают как «backup tool for btrfs subvolumes… to create atomic snapshots and transfer them incrementally to your backup locations».

btrbk делает три вещи:

1. Создаёт снимки по расписанию (ежедневно/еженедельно/…);

2. Инкрементально передаёт их на бэкап — локальный диск или удалённый сервер по SSH;

3. Сам удаляет устаревшие снимки и копии согласно политике хранения.

То есть он держит актуальными ежедневные, еженедельные, ежемесячные и годовые копии и сам ротирует старьё. Запускается из cron или systemd-таймера.

Мой btrbk.conf по шагам

Я взял /etc/btrbk/btrbk.conf.example, выкинул из него все демонстрационные блоки и оставил минимум.

Каталог снимков. По умолчанию btrbk кладёт снимки в _btrbk_snap. Я заменил на .snapshots — тот самый каталог из предыдущего раздела:

snapshot_dir               .snapshots

Важная деталь из комментария в самом конфиге: btrbk не создаёт этот каталог сам, и снимок упадёт, если каталога нет. Один раз сделайте mkdir /.snapshots (и в корне каждого нужного подтома).

Срок хранения и ротация копий. Я заменил пример 20d 10w *m на:

target_preserve            7d 4w 3m 1y

Читается так: на стороне бэкапа хранить 7 дневных, 4 недельных, 3 месячных и 1 годовую копии. Всё, что старше и не попадает под эти слоты, btrbk удаляет автоматически. Локальные снимки-источники при этом живут по своему правилу snapshot_preserve 14d (14 дней) — это короткая «история на откат», полная глубина хранится уже на стороне бэкапа.

Что бэкапим. Минимальный блок для домашнего ПК — раздел /home:

# домашний разделvolume /home  # резервные копии помещать сюда  target /mnt/backup/home  # снимать сам подтом  subvolume .    # имя подтома в снимке    snapshot_name home

Для рабочего сервера я бэкаплю не только /home, но и корень. Добавляется аналогичный блок:

# корневой раздел сервераvolume /  target /mnt/backup/root  subvolume .    snapshot_name root

Бэкап сервера: btrbk run запускается в двух местах. Для рабочего сервера одного локального диска мало — нужна удалённая площадка (третья копия по правилу 3-2-1). И здесь принципиальный момент: btrbk run крутится на двух машинах с двумя разными конфигами.

• На рабочем сервере — для локального бэкапа: сделать снимки и сложить их на локальный отключаемый диск. Это копии 1 и 2. Конфиг — ровно тот, что выше: блоки volume / и volume /home с локальными target.

• На бэкап-сервере — чтобы он сам вытянул готовые снимки с рабочего сервера к себе. Это копия 3, в другом месте.

Почему за данными ходит бэкап-сервер, а не рабочий толкает их наружу (это вопрос безопасности), и как настроить вытягивающий конфиг и ключ — в разделе для сисадминов ниже.

--- /etc/btrbk/btrbk.conf.example+++ /etc/btrbk/btrbk.conf-snapshot_dir               _btrbk_snap+snapshot_dir               .snapshots-target_preserve         20d 10w *m+# Retention policy for backup targets:+#target_preserve         20d 10w *m+target_preserve            7d 4w 3m 1y+# домашний раздел+volume /home+  # резервные копии помещать сюда+  target /mnt/backup/home+  # снимать сам подтом+  subvolume .+    # имя подтома в снимке+    snapshot_name home

Перед боевым запуском полезно прогнать «вхолостую»:

btrbk -c /etc/btrbk/btrbk.conf dryrunbtrbk -c /etc/btrbk/btrbk.conf run

Под капотом: btrfs send / receive

Инкрементальность держится на паре btrfs send / btrfs receive. send умеет выгрузить дамп подтома в любой поток вывода. А если дать ему два снимка — он выгрузит разницу между ними:

# Полный поток первого снимкаbtrfs send /.snapshots/home.1 | btrfs receive /mnt/backup/home/# Только дельта между двумя снимкамиbtrfs send -p /.snapshots/home.1 /.snapshots/home.2 | btrfs receive /mnt/backup/home/

Первый прогон делает базовый снимок и передаёт его целиком. Каждый следующий прогон делает новый снимок, вычисляет разницу с предыдущим и отправляет на приёмник только изменения. Приёмник — тоже Btrfs, локальный или удалённый. И поскольку это поток на stdout/stdin, его можно прогнать через ssh, gpg, zstd — что угодно. btrbk всю эту механику (поиск общего родителя, инкремент, ротацию) берёт на себя.

Раздел для сисадминов: инкрементальный бэкап по SSH за минуты

Удалённая копия делается с бэкап-сервера: он сам ходит на рабочий сервер по SSH и забирает готовые снимки. На рабочем сервере свой btrbk run уже создал снимки и положил локальную копию (копии 1 и 2) — бэкап-серверу остаётся вытянуть инкремент к себе (копия 3).

Конфиг /etc/btrbk/btrbk.conf на бэкап-сервере — источник удалённый, приёмник локальный:

# На БЭКАП-сервере: вытягиваем готовые снимки с рабочего сервераssh_identity     /etc/btrbk/ssh/id_ed25519backend_remote   btrfs-progs-sudovolume ssh://prod.example.com/  snapshot_dir           .snapshots  snapshot_create        no       # снимки уже сделал btrbk на рабочем сервере  snapshot_preserve_min  all  target_preserve        7d 4w 3m 1y  subvolume root    target /mnt/btr_backup/prod/root  subvolume home    target /mnt/btr_backup/prod/home

Почему вытягивает бэкап-сервер, а не наоборот. Это вопрос безопасности, а не вкуса. Ключ и доступ держит бэкап-сервер; рабочий сервер про хранилище не знает ничего и доступа к нему не имеет. Если рабочий сервер взломают или он поймает шифровальщик — атакующий физически не дотянется до бэкапов: у скомпрометированной машины нет ни ключа, ни маршрута до хранилища. При обратной схеме (рабочий сам толкает копию наружу) ключ к хранилищу лежал бы на самой уязвимой машине и достался бы атакующему вместе с ней. Бэкап должен сам приходить за данными в защищаемую систему, а не наоборот.

Это общепринятый принцип безопасного бэкапа, например, документация BorgBackup (команда borg — популярная опенсорсная программа резервного копирования) в разделе «How can I protect against a hacked backup client?» прямо рекомендует pull-режим против скомпрометированного клиента. И сам btrbk документирует эту схему в btrbk.conf.example блоком «Resume backups from remote host which runs its own btrbk instance» — это ровно тот pull-конфиг, что выше.

Безопасная настройка SSH. На рабочем сервере не нужен для бэкап-сервера ни root, ни шелл. btrbk поставляется со скриптом-фильтром ssh_filter_btrbk.sh. Кладём его на рабочий сервер и в ~/.ssh/authorized_keys ограничиваем ключ бэкап-сервера ролью «только отдать снимки» (--send — режим «чтение наружу», -p — ограничить путём):

command="/usr/share/btrbk/scripts/ssh_filter_btrbk.sh -l --send -p /",restrict ssh-ed25519 AAAA...ключ бэкап-сервера...

Даже если взломан сам бэкап-сервер, его ключ к рабочему серверу умеет только читать снимки указанных путей — ни удалить, ни зашифровать боевые данные он не может. Эта строка command="…" — не команда, которую вы где-то набираете: она один раз вписывается в authorized_keys на рабочем сервере, и sshd сам подставляет её при входе по ключу бэкап-сервера.

Почему это занимает минуты, а не часы. По проводу едет не весь /home, а btrfs send -p между вчерашним и сегодняшним снимком — голая дельта на уровне блоков. Переименовали каталог на 100 ГБ? Уйдёт несколько килобайт метаданных. Ночной инкремент сервера, где за сутки реально поменялись единицы гигабайт, передаётся за минуты по обычному каналу.

Расписание — два btrbk run. На каждой машине свой cron, ночью; бэкап-сервер запускается чуть позже, когда снимки на рабочем сервере уже готовы:

# на РАБОЧЕМ сервере (свой btrbk.conf) — локальные копии20 2 * * *  root  /usr/bin/btrbk run# на БЭКАП-сервере (свой btrbk.conf) — вытянуть инкремент с рабочего сервера40 2 * * *  root  /usr/bin/btrbk run

Команда одна и та же — btrbk run, разные только конфиги на каждой стороне. Руками в любой момент — то же самое (btrbk dryrun — холостой прогон). Длинные строки с ssh_filter_btrbk.sh нигде набирать не нужно: btrbk run вызываете вы, а command="…" за вас вызывает sshd.

Разовая настройка двух конфигов и одного ключа — и дальше рабочий сервер каждую ночь делает локальные копии, а бэкап-сервер сам приходит за инкрементом и чистит старьё по политике 7d 4w 3m 1y. «Правильный бэкап» перестаёт быть проектом и становится двумя строчками в cron.

Загрузка со снимков: grub-btrfs

Приятный бонус: утилита grub-btrfs добавляет в меню GRUB пункты для загрузки с любого read-only снимка. Сломалось обновление системы — перезагружаемся, выбираем в меню вчерашний снимок и грузимся с рабочей системы. Идёт в комплекте с демоном, который сам перегенерирует меню GRUB при создании/удалении снимков.

Названия пакета по дистрибутивам:

Если в вашем дистрибутиве (или, как в Gentoo, в основном репозитории) пакета нет, grub-btrfs можно поставить из исходников. Исходники и инструкция по установке — на странице проекта на GitHub: github.com/Antynea/grub-btrfs. Это make install плюс включение демона (grub-btrfsd), который сам следит за каталогом снимков и перегенерирует меню GRUB.

Связка получается отличная: перед рискованным апдейтом — create_snapshot.sh before_update (с флагом -r, чтобы снимок был read-only — см. выше), обновление, при беде — выбор снимка прямо в загрузчике. Откат системы измеряется не часами переустановки, а одной перезагрузкой.

Заключение

Соберём всё вместе.

• Btrfs даёт мгновенные copy-on-write снимки и передачу изменений на уровне блоков и метаданных — переименование каталога на 100 ГБ стоит несколько килобайт трафика, а не 100 ГБ.

• btrbk превращает это в автоматический бэкап с ротацией: ежедневные, недельные, месячные, годовые копии без вашего участия.

• Скорость и экономия места. Само резервное копирование через btrbk крайне быстрое и экономное по диску: передаётся и хранится только блочная дельта, а снимки делят между собой общие данные. На том же объёме помещается в разы больше копий, чем у традиционных средств, — глубокую историю можно держать почти даром.

• Бэкап по SSH даёт третью, удалённую копию правила 3-2-1, и ночной инкремент рабочего сервера уезжает за минуты.

• grub-btrfs превращает откат системы в выбор пункта меню при загрузке.

И помните про «бэкап Шрёдингера» — фольклорное правило сисадминов: состояние резервной копии неизвестно, пока не предпринята попытка восстановления. Пока вы не восстановились хотя бы один раз — у вас не бэкап, а папка, про которую вы лишь надеетесь, что это бэкап. Поэтому, настроив всё по этой статье, не поленитесь провести учебное восстановление: поднимите снимок на тестовой машине и убедитесь, что данные на месте. Один такой эксперимент стоит дешевле, чем один звонок в контору по восстановлению данных в три часа ночи.

Применяйте — и пусть ваши данные живут ВЕЧНО!

© 2026 ООО «МТ ФИНАНС»