bup-split - сохранять отдельные файлы в наборы резервных копий
bup split [-t] [-c] [-n name] COMMON_OPTIONS
bup split -b COMMON_OPTIONS
bup split –copy COMMON_OPTIONS
bup split –noop [-t|-b] COMMON_OPTIONS
[-r host:path] [-v] [-q] [-d seconds-since-epoch] [--bench] [--max-pack-size=bytes] [-#] [--bwlimit=bytes] [--max-pack-objects=n] [--fanout=count] [--keep-boundaries] [--git-ids | filenames...]
bup split объединяет содержимое заданных файлов (или, если имена файлов не заданы, считывает из стандартного ввода), разбивает содержимое на куски размером около 8 КБ с использованием алгоритма скользящей контрольной суммы и сохраняет куски в репозиторий bup. Чанки, которые ранее были сохранены, больше не сохраняются (т.е. они "дедуплицируются").
Из-за того, как работает скользящая контрольная сумма, фрагменты, как правило, очень стабильны при изменениях в данном файле, включая добавление, удаление и изменение байтов.
Например, если вы используете bup split для резервного копирования XML-дампа базы данных, и XML-файл немного меняется от одного запуска к другому, почти все данные все равно будут дедуплицированы, а размер каждой резервной копии после первой обычно будет быть совсем маленьким.
Другой метод заключается в передаче вывода программ tar(1) или cpio(1) в bup split. Когда отдельные файлы в архиве немного изменяются, добавляются или удаляются, bup по-прежнему эффективно обрабатывает оставшуюся часть архива. (Обратите внимание, что сохранение bup обычно является более эффективным способом добиться этого.)
Чтобы вернуть данные, используйте bup-join(1).
Эти параметры выбирают основное поведение команды, причем -n является наиболее вероятным выбором.
после создания набора данных создайте ветку git с именем name, чтобы к ней можно было получить доступ, используя это имя. Если name уже существует, новый набор данных будет считаться потомком старого name. (Таким образом, вы можете постоянно создавать новые наборы данных с тем же именем, а затем просматривать историю этого набора данных, чтобы увидеть, как он менялся с течением времени.) Исходные данные также будут доступны в виде файла верхнего уровня с именем «данные» в VFS, доступный через bup fuse, bup ftp и т. д.
вывести идентификатор дерева git результирующего набора данных.
выведите идентификатор git commit полученного набора данных.
выведите серию идентификаторов git blob, которые соответствуют частям в наборе данных. Несовместимо с -n, -t и -c.
читать данные и разбивать их на блоки на основе алгоритма скользящей контрольной суммы «bupsplit», но ничего не сохранять в репо. Можно комбинировать с -b или -t для вычисления (но не сохранения) больших двоичных объектов git или идентификаторов дерева для набора данных. Это в основном полезно для бенчмаркинга и проверки алгоритма bupsplit. Несовместим с -n и -c.
как --noop, но также записывать данные в стандартный вывод. Это может быть полезно для оценки скорости чтения+разделения+записи для больших объемов данных. Несовместимо с -n, -t, -c и -b.
сохранить набор резервных копий на указанный удаленный сервер. Если путь не указан, используется путь по умолчанию на удаленном сервере (вам все равно нужно включить `:'). Подключение к удаленному серверу осуществляется с помощью SSH. Если вы хотите указать, какой порт, пользователя или закрытый ключ использовать для SSH-соединения, мы рекомендуем вам использовать файл ~/.ssh/config. Несмотря на то, что место назначения удалено, все равно требуется локальный репозиторий bup.
указать дату, вписанную в коммит (секунды с 1970-01-01).
отключить сообщения о прогрессе.
увеличить многословность (можно использовать более одного раза).
stdin — это список идентификаторов объектов git вместо необработанных данных. bup split прочитает содержимое каждого именованного объекта git (если он существует в репозитории bup) и разделит его. Это может быть полезно для преобразования репозитория git с большими двоичными файлами для использования хэш-разбиения в стиле bup. Эта опция, вероятно, наиболее полезна в сочетании с --keep-boundaries.
если в командной строке указано несколько имен файлов, они обычно объединяются вместе, как если бы все содержимое было взято из одного файла. То есть созданный набор больших двоичных объектов/деревьев идентичен тому, что был бы, если бы был один входной файл. Однако, если вы используете --keep-boundaries, каждый файл разделяется отдельно. Вы по-прежнему получаете только одно дерево, коммит или серию BLOB-объектов, но каждый BLOB-объект происходит только из одного из файлов; конец одного из входных файлов всегда заканчивается большим двоичным объектом.
вывести контрольные тайминги в stderr.
никогда не создавайте git packfiles размером больше заданного количества байтов. По умолчанию 1 миллиард байт. Обычно нет причин менять это.
никогда не создавайте git packfiles с большим количеством объектов, чем указано. По умолчанию 200 тысяч объектов. Обычно нет причин менять это.
при разделении очень больших файлов старайтесь, чтобы количество элементов в деревьях составляло в среднем numobjs.
не передавайте серверу больше bytes/sec байт в секунду. Это хорошо для того, чтобы ваши резервные копии не поглощали всю пропускную способность вашей сети. Используйте суффикс, например k, M или G, чтобы указать число, кратное 1024, 1024*1024, 1024*1024*1024 соответственно.
установите уровень сжатия на # (значение от 0 до 9, где 9 — самый высокий уровень, а 0 — отсутствие сжатия). По умолчанию 1 (быстрое, слабое сжатие).
$ tar -cf - /etc | bup split -r myserver: -n mybackup-tar
tar: Removing leading /' from member names
Indexing objects: 100% (196/196), done.
$ bup join -r myserver: mybackup-tar | tar -tf - | wc -l
1961bup-join(1), bup-index(1), bup-save(1), bup-on(1), ssh_config(5)
Часть люкса bup(1).
Эйвери Пеннарун apenwarr@gmail.com.