Borg: marcadores de posición de tamaño para la lista de borg<repo/>
borg list solo admite archivo de lista, barchive, time e id para un archivo. Sin embargo, cuando veo que necesito espacio y quiero eliminar archivos grandes (por ejemplo, debido a https://github.com/borgbackup/borg/issues/2870), me gustaría ver una descripción general de todos los tamaños de archivo para encontrar los más grandes y eliminarlos potencialmente.
Sé que podría borg info cada archivo, pero esto lleva algo de tiempo y es inconveniente para muchos archivos.
Por supuesto, solo me interesa el "tamaño deduplicado" de "este archivo".
Pero si lo desea, también puede resumir los valores (o cómo lo hace) y mostrar una línea "tamaño de todos los archivos: XY GB" en la parte inferior.
Tal vez necesite almacenar en caché esta información de alguna manera / en algún lugar, pero esto debería ser posible, ya que, por lo general, el tamaño de un archivo no cambia y, por lo tanto, el caché nunca tiene que caducar (a menos que se elimine un archivo).
rugk
Todos 5 comentarios
Hasta hace poco, faltaba la infraestructura necesaria para esto; la agregué (a la rama maestra) cuando implementé el marcador de posición "comentario" para borg list <repo> . Ahora puede calcular cosas bajo demanda y no solo mostrar datos de la entrada del manifiesto, como antes.
Pero tenga en cuenta que calcular cualquier cosa que necesite leer todos los metadatos del archivo será lento, especialmente. si la lista muestra muchos archivos y / o se accede al repositorio a través de una conexión lenta.
ThomasWaldmann
en 24 jul. 2017
borg info -a '*' , borg info --last/first x
enkore
en 24 jul. 2017
borg info -a '*'
Es interesante que esto sea posible, pero en gran medida es lento.
Pero tenga en cuenta que calcular cualquier cosa que necesite leer todos los metadatos del archivo será lento, especialmente. si la lista muestra muchos archivos y / o se accede al repositorio a través de una conexión lenta.
Sí, por eso dije: ¿No puedes guardar este hecho en caché?
rugk
en 24 jul. 2017
Es interesante que esto sea posible, pero en gran medida es lento.
El _tamaño duplicado_ debe calcularse y no se puede almacenar en caché, por lo que esto siempre será un poco lento, aunque # 2764 lo hace bastante más rápido.
enkore
en 24 jul. 2017
Deseando esta característica yo mismo, pegué esto (técnicamente: guiño :) de una sola línea para obtener una lista de archivo como me gustaría que se vea:
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)
Utiliza jq para formatear el JSON y numfmt de coreutils para que los tamaños sean legibles por humanos. El resultado se ve así (recortado a un conjunto representativo de líneas):
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
Con solo 39 archivos, la velocidad está bien, pero supongo que hacerlo con --last 1 como parte de la ejecución de la copia de seguridad y almacenar esto en un registro separado para consultar bajo demanda será la forma de usarlo en la práctica.
elho
en 22 jun. 2019
Temas relacionados
ypid
·
6Comentarios
rugk
·
3Comentarios
phdoerfler
·
6Comentarios
verygreen
·
4Comentarios
depresnak
·
6Comentarios
Comentario más útil
Deseando esta característica yo mismo, pegué esto (técnicamente: guiño :) de una sola línea para obtener una lista de archivo como me gustaría que se vea:
Utiliza
jqpara formatear el JSON ynumfmtdecoreutilspara que los tamaños sean legibles por humanos. El resultado se ve así (recortado a un conjunto representativo de líneas):Con solo 39 archivos, la velocidad está bien, pero supongo que hacerlo con
--last 1como parte de la ejecución de la copia de seguridad y almacenar esto en un registro separado para consultar bajo demanda será la forma de usarlo en la práctica.