Borg: marcadores de posição de tamanho para lista de borg<repo/>
borg list suporta apenas arquivo de listagem, barchive, hora e id de um arquivo. Quando, por exemplo, vejo que preciso de espaço e quero excluir arquivos grandes (por exemplo, por causa de https://github.com/borgbackup/borg/issues/2870), gostaria de ter uma visão geral de todos os tamanhos de arquivo para encontre os maiores e, potencialmente, exclua-os.
Eu sei que poderia borg info cada arquivo, mas isso leva algum tempo e é inconveniente para muitos arquivos.
Claro, estou interessado apenas no "tamanho desduplicado" de "este arquivo".
Mas se quiser, você também pode somar os valores (ou como você faz isso) e exibir uma linha "tamanho de todos os arquivos: XY GB" na parte inferior.
Talvez você precise armazenar essas informações de alguma forma / em algum lugar, mas isso deve ser possível, pois, normalmente, o tamanho de um arquivo não muda e, portanto, o cache nunca precisa expirar (a menos que um arquivo seja excluído).
rugk
Todos 5 comentários
Até recentemente, a infraestrutura necessária para isso estava faltando - eu a adicionei (ao branch master) quando implementei o marcador de posição "comentário" para borg list <repo> . Agora ele pode computar coisas sob demanda e não apenas mostrar dados da entrada do manifesto, como antes.
Mas, esteja ciente de que computar qualquer coisa que precise ler todos os metadados do arquivo será lento, esp. se a lista mostra muitos arquivos e / ou repo é acessado através de uma conexão lenta.
ThomasWaldmann
em 24 jul. 2017
borg info -a '*' , borg info --last/first x
enkore
em 24 jul. 2017
borg info -a '*'
É interessante que isso seja possível, mas muito lento.
Mas, esteja ciente de que computar qualquer coisa que precise ler todos os metadados do arquivo será lento, esp. se a lista mostra muitos arquivos e / ou repo é acessado através de uma conexão lenta.
Sim, é por isso que eu disse: você não pode simplesmente esconder esse fato?
rugk
em 24 jul. 2017
É interessante que isso seja possível, mas muito lento.
_Tamanho desduplicado_ tem que ser calculado, e não pode ser armazenado em cache - então isso sempre será um pouco lento, embora # 2764 o torne um pouco mais rápido.
enkore
em 24 jul. 2017
Desejando por esse recurso, juntei esta (tecnicamente: wink :) uma linha para obter uma lista de arquivos como eu gostaria que fosse:
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)
Ele usa jq para formatar o JSON e numfmt de coreutils para tornar os tamanhos legíveis por humanos. O resultado é semelhante a este (cortado para um conjunto representativo de linhas):
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
Com apenas 39 arquivos, a velocidade está ok, mas acho que fazer isso com --last 1 como parte da execução do backup e armazená-lo em um log separado para consultar sob demanda será a maneira de usá-lo na prática.
elho
em 22 jun. 2019
Questões relacionadas
rugk
·
4Comentários
ThomasWaldmann
·
6Comentários
pierreozoux
·
4Comentários
depresnak
·
6Comentários
unlandm
·
4Comentários
Comentários muito úteis
Desejando por esse recurso, juntei esta (tecnicamente: wink :) uma linha para obter uma lista de arquivos como eu gostaria que fosse:
Ele usa
jqpara formatar o JSON enumfmtdecoreutilspara tornar os tamanhos legíveis por humanos. O resultado é semelhante a este (cortado para um conjunto representativo de linhas):Com apenas 39 arquivos, a velocidade está ok, mas acho que fazer isso com
--last 1como parte da execução do backup e armazená-lo em um log separado para consultar sob demanda será a maneira de usá-lo na prática.