Есть ли у btrfs эффективный способ сравнения снимков?

btrfs send, который появился в Linux 3.6 (2012), «генерирует поток изменений между двумя снимками подтома». Вы можете использовать его просто для быстрого сравнения метаданных, добавив --no-data флаг.

btrfs send --no-data -p /snapshots/parent /snapshots/child

Обычно вы бы уронили --no-data flag и направить вывод в btrfs receive, делать инкрементные резервные копии. Например, если /snapshots/parent уже существует в /backup/snapshots/parent, btrfs send будет передавать только эти изменения в /backup файловая система:

btrfs send -p /snapshots/parent /snapshots/child | btrfs receive /backup/snapshots

Я использую стабильную версию Debian, которая делает не было btrfs send, поэтому я искал решение, используя btrfs subvolume find-new.

Обновить: btrfs send был добавлено в Linux 3.6, который был выпущен в 2012 году и включен в стабильную версию Debian к 2015 году.

Если у вас есть snapshot1 и snapshot2, и вы хотите знать, что изменилось в последнем, снимке 2, с момента создания снимка 1, вы можете использовать приведенный ниже сценарий, который предоставляет

btrfs-diff oldsnapshot/ newsnapshot/

в котором будут перечислены все файлы, измененные в снимке новостей / с момента старого снимка /.

#!/bin/bash
usage() { echo $@ >2; echo "Usage: $0 <older-snapshot> <newer-snapshot>" >2; exit 1; }

[ $# -eq 2 ] || usage "Incorrect invocation";
SNAPSHOT_OLD=$1;
SNAPSHOT_NEW=$2;

[ -d $SNAPSHOT_OLD ] || usage "$SNAPSHOT_OLD does not exist";
[ -d $SNAPSHOT_NEW ] || usage "$SNAPSHOT_NEW does not exist";

OLD_TRANSID=`btrfs subvolume find-new "$SNAPSHOT_OLD" 9999999`
OLD_TRANSID=${OLD_TRANSID#transid marker was }
[ -n "$OLD_TRANSID" -a "$OLD_TRANSID" -gt 0 ] || usage "Failed to find generation for $SNAPSHOT_NEW"

btrfs subvolume find-new "$SNAPSHOT_NEW" $OLD_TRANSID | sed '$d' | cut -f17- -d' ' | sort | uniq

Объяснять: btrfs subvolume find-new находит измененные файлы после конкретное «поколение» снимков. Он также сообщает номер текущего поколения.

Предостережения

например сделайте ежедневный снимок случая подобъема:

mkdir test && cd test
btrfs subvolume create live
date >live/foo1
date >live/bar1
btrfs subvolume snapshot live/ snap1
date >live/foo2  # new file
date >>live/bar1 # modify file
rm live/foo1     # delete file
btrfs subvolume snapshot live/ snap2
date >live/foo3  # new file
mv live/bar{1,2} # rename file
rm live/foo2     # delete file

Что изменилось между snap1 и snap2?

$ btrfs-diff snap1/ snap2/
bar1
foo2

Итак, мы можем увидеть новый файл, увидеть измененный файл, но об удалении не сообщается. Это потому, что команда сообщает о файлах, которые существуют, а не о тех, которых сейчас нет.

Что изменилось между snap2 и live subvolume?

$ btrfs-diff snap2/ live/
foo3

о переименованном файле не сообщается. Его данные не изменились.

Что если мы добавим данные в переименованный файл

date >>live/bar2
btrfs-diff snap2/ live/
bar2
foo3

ОК, имеет смысл. Но давайте сделаем новый файл

date >live/lala
btrfs-diff snap2/ live/
bar2
foo3

а! где лала?. Если вы добавите еще один файл, lala появляется. Так что это поведение немного странное. Вероятно, поэтому в вики говорится:

Подход find-new имеет некоторые серьезные ограничения и поэтому не может использоваться для чего-то вроде отправки / получения.

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

Это поддерживается инструментом для удобства создания снимков. snapper.

sudo snapper -c config diff 445..446

Конечно, это требует, чтобы вы использовали snapper для ваших снимков.

Идентификаторы этих снимков можно найти с помощью snapper list -a. К сожалению, на момент написания snapper не поддерживал снимки списка для одной конфигурации, хотя эти числа можно найти по именам подтомов.