Borg: заполнители размера для списка borg<repo/>

До недавнего времени инфраструктура, необходимая для этого, отсутствовала - я добавил ее (в главную ветку), когда реализовал заполнитель «комментарий» для borg list <repo> . Теперь он может вычислять данные по запросу, а не только отображать данные из записи манифеста, как раньше.

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

borg info -a '*' , borg info --last/first x

borg info -a '*'

Интересно, что это возможно, но в значительной степени медленно.

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

Да, вот почему я сказал: нельзя просто засекретить этот факт?

Интересно, что это возможно, но в значительной степени медленно.

_Дедуплицированный размер_ должен быть рассчитан, и его нельзя кэшировать - так что это всегда будет немного медленным, хотя # 2764 делает его намного быстрее.

Желая самой использовать эту функцию, я сложил это (технически: wink :) однострочное письмо, чтобы получить список архивов, как мне бы хотелось, чтобы он выглядел:

printf 'Archive\t\t\t\t\tOrig\tComp\tDedup\n'; printf '%-32.32s\t%s\t%s\t%s\n' $(borg info --json --sort-by name --glob-archives '*' REPO | jq '.archives[] | "\(.name) \(.stats.original_size) \(.stats.compressed_size) \(.stats.deduplicated_size)"' | sed --expression='s/^"//;s/"$//' | numfmt --field='2-4' --to=iec)

Он использует jq для форматирования JSON и numfmt из coreutils чтобы сделать размеры удобочитаемыми. Результат выглядит следующим образом (обрезанный до репрезентативного набора строк):

Archive                 Orig    Comp    Dedup
hostname-home-20190613-090600       288G    92G 12K
hostname-home-20190613-091013       288G    92G 117K
hostname-home-20190617-005337       220G    61G 6.9M
hostname-home-20190617-022904       288G    92G 16M
hostname-home-20190617-225658       288G    92G 40K
hostname-sysconfig-20190617-023108  12M 3.2M    40K
hostname-sysconfig-20190617-225820  12M 3.2M    32K
hostname-sysconfig-20190618-144623  12M 3.2M    105K
hostname-sysconfig-20190621-224259  13M 3.3M    110K
hostname-system-20190613-081754     300G    97G 20M
hostname-system-20190613-091212     300G    97G 14M
hostname-system-20190618-144635     300G    97G 37M
hostname-system-20190621-224311     308G    98G 4.6M
hostname-system-20190621-230350     308G    98G 617K

Со скоростью всего 39 архивов все в порядке, но я думаю, что делать это с --last 1 как часть резервного копирования и хранить это в отдельном журнале для консультации по запросу - это способ использовать его на практике.