Borg: Platzhalter für die Größe der Borg-Liste<repo/>

Erstellt am 24. Juli 2017  ·  5Kommentare  ·  Quelle: borgbackup/borg

borg list unterstützt nur Auflistungsarchiv, barchive, Zeit und ID für ein Archiv. Wenn ich zB sehe, dass ich Platz benötige und große Archive löschen möchte (zB wegen https://github.com/borgbackup/borg/issues/2870), möchte ich eine Übersicht über alle Archivgrößen sehen finden Sie die größten und löschen Sie sie möglicherweise.
Ich weiß, dass ich jedes Archiv borg info , aber das dauert einige Zeit und ist für viele Archive unbequem.
Natürlich interessiert mich nur die "deduplizierte Größe" von "diesem Archiv".

Wer möchte, kann aber auch die Werte aufsummieren (oder wie man das macht) und unten eine Zeile "Größe aller Archive: XY GB" anzeigen.

Möglicherweise müssen Sie diese Informationen irgendwie/irgendwo zwischenspeichern, aber dies sollte möglich sein, da sich die Größe eines Archivs normalerweise nicht ändert und der Cache daher nie ablaufen muss (es sei denn, ein Archiv wird gelöscht).

Hilfreichster Kommentar

Da ich mir dieses Feature selbst gewünscht habe, habe ich diesen (technisch :wink:) One-Liner zusammengeschlagen, um eine Archivliste zu erhalten, wie ich sie gerne hätte:

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)

Es verwendet jq um den JSON zu formatieren und numfmt von coreutils um die Größen lesbar zu machen. Das Ergebnis sieht wie folgt aus (auf repräsentativen Liniensatz getrimmt):

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

Mit nur 39 Archiven ist die Geschwindigkeit in Ordnung, aber ich denke, es mit --last 1 als Teil des Backup-Laufs zu tun und dies in einem separaten Protokoll zu speichern, um es bei Bedarf zu konsultieren, wird der Weg sein, es in der Praxis zu verwenden.

Alle 5 Kommentare

Bis vor kurzem fehlte die dafür notwendige Infrastruktur - ich habe sie (zum Master-Zweig) hinzugefügt, als ich den Platzhalter "Kommentar" für borg list <repo> implementiert habe. Es kann jetzt Dinge nach Bedarf berechnen und nicht wie zuvor nur Daten aus dem Manifesteintrag anzeigen.

Beachten Sie jedoch, dass die Berechnung von allem, was zum Lesen der gesamten Archivmetadaten erforderlich ist, langsam sein wird, insbesondere. wenn die Auflistung viele Archive und/oder Repo anzeigt, wird über eine langsame Verbindung zugegriffen.

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

borg info -a '*'

Interessant, dass dies möglich ist, aber es ist weitgehend langsam.

Beachten Sie jedoch, dass die Berechnung von allem, was zum Lesen der gesamten Archivmetadaten erforderlich ist, langsam sein wird, insbesondere. wenn die Auflistung viele Archive und/oder Repo anzeigt, wird über eine langsame Verbindung zugegriffen.

Ja, deshalb habe ich gesagt: Kannst du diese Tatsache nicht einfach zwischenspeichern?

Interessant, dass dies möglich ist, aber es ist weitgehend langsam.

_Deduplizierte Größe_ muss berechnet werden und kann nicht zwischengespeichert werden — das wird also immer etwas langsam sein, obwohl #2764 es um einiges schneller macht.

Da ich mir dieses Feature selbst gewünscht habe, habe ich diesen (technisch :wink:) One-Liner zusammengeschlagen, um eine Archivliste zu erhalten, wie ich sie gerne hätte:

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)

Es verwendet jq um den JSON zu formatieren und numfmt von coreutils um die Größen lesbar zu machen. Das Ergebnis sieht wie folgt aus (auf repräsentativen Liniensatz getrimmt):

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

Mit nur 39 Archiven ist die Geschwindigkeit in Ordnung, aber ich denke, es mit --last 1 als Teil des Backup-Laufs zu tun und dies in einem separaten Protokoll zu speichern, um es bei Bedarf zu konsultieren, wird der Weg sein, es in der Praxis zu verwenden.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

phdoerfler picture phdoerfler  ·  6Kommentare

verygreen picture verygreen  ·  4Kommentare

auanasgheps picture auanasgheps  ·  5Kommentare

chebee7i picture chebee7i  ·  5Kommentare

htho picture htho  ·  5Kommentare