Restic: viel effizienter mit großen Pflaumen umgehen

Da die Leistung für Wiederherstellungen für große Repos/Repos mit großen Dateien jetzt durch den Out-of-Order-Zweig von @ifedorenko aufgelöst wird, sieht es so aus, als wäre dies der nächste Stein für die Verwendung von Restic in Multi-Terabyte-Umgebungen, in denen das Repo nicht lokal ist Festplatte und es wird nicht über den REST-Server auf einer Loopback-Schnittstelle zugegriffen.

Derzeit läuft eine leere Bereinigung (Bereinigung eines Snapshots, der zu 100 % mit einem vorherigen Snapshot identisch war) gegen ein Repo in einem AZ-lokalen S3-Bucket auf High-End-AWS-Instances mit einer theoretischen Bandbreite von 10 Gbit/s bei:

1) Erstellen eines neuen Index – ~160 Packungen/Sekunde
2) Auffinden von Daten, die noch verwendet werden – insgesamt 56 Sekunden
3) Umschreiben von Packs – ~3 Packs/Sekunde

160 Pakete/Sekunde sind langsam, aber noch tolerabel (~80 Minuten Laufzeit gegenüber einem 3-TB-Repo).

Aber das Umschreiben bei 3 Packs/Sekunde läuft fast 10 Stunden, selbst für mein Noop-Prune (es werden 0 Packs gelöscht und 111098 Packs neu geschrieben, dies gibt 180,699 GiB frei). Für eine sinnvolle Bereinigung eines großen Repos frieren Sie neue Backups für mehr als 24 Stunden ein.

Es sieht so aus, als würden die Paketumschreibungen derzeit in einem einzigen Thread stattfinden, sodass es durchaus hilfreich sein könnte, die Ausführung über mehrere Worker hinweg zuzulassen, selbst wenn der aktuelle Copy-and-Purge-Ansatz beibehalten wird.

Persönlich würde ich keine Zeit damit verbringen, die aktuelle Blocking-Prune-Implementierung zu optimieren, ich denke, dass Non-Blocking-Prune die bessere langfristige Lösung ist.

Daran habe ich kürzlich gearbeitet. Folgendes habe ich getan:

• Laden Sie den vorhandenen Index, anstatt alle Pakete zu scannen (und scannen Sie dann alle Pakete, die nicht im Index waren).
• Parallelisiertes Scannen der Snapshots auf verwendete Blobs
• Parallelisiertes Umschreiben teilweise verwendeter Packs
• Schreiben Sie den neuen Index unter Verwendung der bereits im Speicher befindlichen Indexinformationen

Ich arbeite derzeit daran, den Grad der Parallelität herauszufinden, der zum Umschreiben teilweise verwendeter Pakete verwendet werden soll (ich plane, dies auf der konfigurierten Anzahl von Verbindungen für das Backend zu basieren). Ich muss auch viel mehr Tests in verschiedenen Fehlerszenarien durchführen.

Hier sind einige Leistungszahlen (unter Verwendung eines Repositorys mit 875 GiB Daten, etwa 180.000 Packs und 36 Snapshots, unter Verwendung eines Loopback-Rest-Servers als Backend):

• Aktueller Code:
  
  
  
  • 35–40 Minuten (jeweils), um den Index am Anfang und am Ende der Pflaume aufzubauen (insgesamt 70–80 Minuten)
  
  
  • 4-5 Minuten, um gebrauchte Blobs zu finden
  
  
  • Ein paar Sekunden, um teilweise verwendete Packs neu zu schreiben
  
  
• Meine Änderungen bisher:
  
  
  
  • Ein paar Sekunden, um den vorhandenen Index zu laden (etwas länger, wenn nicht indizierte Pakete gescannt werden müssen)
  
  
  • Weniger als 2 Minuten, um gebrauchte Blobs zu finden
  
  
  • Ein paar Sekunden, um den neuen Index zu schreiben
  
  

Ich plane auch, einen generierten Testfall einzurichten, der viel mehr Paketumschreibungen beinhalten wird.

Courtney:

Klingt super vielversprechend! Wollten Sie bestätigen, dass dies die Branche ist, in der Sie arbeiten? Ich teste gerne.

https://github.com/cbane/restic/tree/prune-aggressive

Nein, dieser Zweig ist Teil des Forks aus dem Haupt-Repository. Ich habe meine Änderungen noch nirgendwo veröffentlicht. Ich sollte in der Lage sein, meine Work-in-Progress-Version in ein paar Tagen auf GitHub zu pushen, damit Sie sie ausprobieren können.

OK, ich habe eine Version, die für andere Leute zum Ausprobieren bereit sein sollte. Es befindet sich in diesem Zweig: https://github.com/cbane/restic/tree/prune-speedup

Aktuelle Einschränkungen:

• Ich habe keine automatische Einstellung der Anzahl der Umpackarbeiter implementiert. Legen Sie zunächst die Umgebungsvariable RESTIC_REPACK_WORKERS auf die Anzahl der Worker fest, die Sie verwenden möchten. Es wird standardmäßig auf 4 gesetzt, wenn es nicht gesetzt ist.
• An der Fehlerbehandlung beim Umpacken muss ich noch arbeiten. Ich habe keine wirklichen Änderungen gegenüber dem bestehenden Single-Thread-Umpacken vorgenommen; Ich muss mir die verschiedenen Fehlerfälle ansehen und sicherstellen, dass das parallele Umpacken keine Probleme verursacht.

Ähm, das sieht toll aus. Danke für deine Arbeit!

Ich habe dies ein wenig mit einer Kopie von 3 TB+ Repo in Amazon S3 getestet und bisher sieht es fantastisch aus. Ein Repack-Prune, das Wochen gedauert hätte, ist jetzt in weniger als einer Stunde abgeschlossen, und das verwendet relativ langsames EBS als tmp-Speicherplatz.

Ein echter Game Changer hier! Großartige Arbeit, @cbane!

Eek, mir ist aufgefallen, dass ich den Lauf falsch eingeschätzt habe.

Ein Bereich, der immer noch Single-Threading ist und so aussieht, als könnte er von Parallelisierung profitieren, ist der Schritt „Nach Paketen suchen, die nicht im Index sind“ – das kann immer noch 3-4 Stunden in Multi-Terabyte-Repositorys dauern – aber das ist immer noch eine gewaltige, massive Verbesserung, danke!

@cbane Ich konnte kein Problem mit Ihrem Fork eröffnen, also lassen Sie mich wissen, ob es einen besseren Ort dafür gibt.

Bei einem weiteren Testlauf schlug das Umpacken ganz am Ende fehl (Umschreiben des letzten Pakets) und lief mit 32 Arbeitern:

found 1396709 of 2257203 data blobs still in use, removing 860494 blobs
will remove 0 invalid files
will delete 119301 packs and rewrite 88485 packs, this frees 896.269 GiB
using 32 repack workers
Save(<data/c136027b25>) returned error, retrying after 723.31998ms: client.PutObject: Put https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxxx: Connection closed by foreign host https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxx. Retry again.
Save(<data/09d4692900>) returned error, retrying after 538.771816ms: client.PutObject: Put https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxxx: Connection closed by foreign host https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxxx. Retry again.
Save(<data/23d0d4f842>) returned error, retrying after 617.601934ms: client.PutObject: Put https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxx: Connection closed by foreign host https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxx. Retry again.
[10:02] 100.00%  88484 / 88485 packs rewritten
panic: reporting in a non-running Progress

goroutine 386596 [running]:
github.com/restic/restic/internal/restic.(*Progress).Report(0xc42011c2c0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0)
        internal/restic/progress.go:122 +0x242
github.com/restic/restic/internal/repository.Repack.func2(0x8, 0xe17f58)
        internal/repository/repack.go:66 +0x136
github.com/restic/restic/vendor/golang.org/x/sync/errgroup.(*Group).Go.func1(0xc4389246c0, 0xc56f509160)
        vendor/golang.org/x/sync/errgroup/errgroup.go:57 +0x57
created by github.com/restic/restic/vendor/golang.org/x/sync/errgroup.(*Group).Go
        vendor/golang.org/x/sync/errgroup/errgroup.go:54 +0x66

Ich habe eine neue Version verfügbar, in der gleichen Filiale wie zuvor. Ich habe auch gegen master rebasiert.

Hier sind die wichtigsten Änderungen gegenüber der vorherigen Version:

• Das Umpacken wurde so umgestellt, dass jeder Arbeiter alle Phasen des Umpackens einer einzelnen Packung in eine Pipeline durchführt.
• Der gemeldete Absturz am Ende des Neupackens wurde behoben.
• Das Neupacken skaliert jetzt automatisch die Anzahl der Worker für die Pipeline-Stufen basierend auf der Anzahl der CPUs und dem konfigurierten Verbindungslimit für das Back-End. (Die Umgebungsvariable RESTIC_REPACK_WORKERS wird nicht mehr verwendet.)
• Kleinere Änderungen beim Auffinden verwendeter Blobs.
• Parallelisiertes Scannen unbekannter Packungen.

Ich möchte noch etwas daran arbeiten, gebrauchte Blobs zu finden. Derzeit wird jeder Snapshot von einem einzelnen Worker verarbeitet. Dadurch können CPU-Ressourcen ungenutzt bleiben, wenn weniger Snapshots als CPUs vorhanden sind oder wenn große Größenunterschiede zwischen Snapshots bestehen. Ich möchte, dass die Verarbeitung von Teilbäumen auf verschiedene Worker verteilt wird. Ich glaube, ich weiß, wie das geht, ich muss es nur tatsächlich umsetzen.

Ich würde dazu tendieren, Dinge zu diesem Thema (oder dem zukünftigen Pull-Request dafür) weiter zu diskutieren, damit alles hier im Haupt-Repository bleibt, anstatt sich zu verteilen.

Gerade getestet. Es behebt den Absturz am Ende des Umpackens und funktioniert wirklich, wirklich gut.

Der einzige zusätzliche Ort, der von einer erhöhten Parallelität profitieren könnte, ist das Löschen von Paketen, das derzeit Single-Threading ist.

Dies ist besonders hart während der ersten Beschneidung eines Repos, das zuvor nicht bereinigt werden konnte, da es _viele_ Packs gibt, die gelöscht werden müssen.

Selbst mit Single-Thread-Löschung dauert ein tägliches Vergessen/Prune für ein 1,7 TB großes, 356.000 Pack-Repository, das 14,7.000 Packs neu schreibt und 33.000 Packs löscht, jetzt knapp 20 Minuten.
Früher war es unmöglich, überhaupt zu beschneiden.

Ausgezeichnete Arbeit, danke!

OK, ich habe eine andere Version zur Verfügung. Die einzige wirkliche Änderung dieses Mal ist, dass ungenutzte Packs jetzt parallel gelöscht werden (plus ein paar kleinere Änderungen an einigen früheren Änderungen). Ich habe das modifizierte Snapshot-Scannen implementiert, aber es hat nicht genug Geschwindigkeit gebracht und es gab keine gute Möglichkeit, dem Benutzer den Fortschritt zu melden, also habe ich es wieder entfernt.

Ich plane, bald einen Pull-Request dafür zu eröffnen, vorausgesetzt, dass nichts kaputt gegangen ist. (Ich werde jedoch zuerst den Verlauf bereinigen.) @fd0 , möchten Sie sich das zuerst ansehen?

Hat bei unserem Testlauf super funktioniert. 30.000 Pakete in 225 Sekunden umgeschrieben, 73.000 Pakete in 50 Sekunden gelöscht.

Die Gesamtlaufzeit für ein 1,74-TiB-Repo in S3 mit 32 überlebenden Snapshots betrug etwas mehr als 6 Minuten.

Brillante Arbeit.

@cbane Ich habe Ihren Zweig https://github.com/cbane/restic/tree/prune-speedup ausprobiert

aber das ist der Fehler, den ich erhalte :(

root<strong i="9">@srv</strong> ~/restic-backups # restic --no-cache prune
repository 49b87c6a opened successfully, password is correct
listing files in repo
loading index for repo
[0:28] 1.01%  30 / 2982 index files
pack cbbebd8d already present in the index
github.com/restic/restic/internal/index.(*Index).AddPack
    internal/index/index.go:266
github.com/restic/restic/internal/index.Load.func1
    internal/index/index.go:230
github.com/restic/restic/internal/repository.(*Repository).List.func1
    internal/repository/repository.go:640
github.com/restic/restic/internal/backend.(*RetryBackend).List.func1.1
    internal/backend/backend_retry.go:133
github.com/restic/restic/internal/backend/rest.(*Backend).listv2
    internal/backend/rest/rest.go:423
github.com/restic/restic/internal/backend/rest.(*Backend).List
    internal/backend/rest/rest.go:358
github.com/restic/restic/internal/backend.(*RetryBackend).List.func1
    internal/backend/backend_retry.go:127
github.com/cenkalti/backoff.RetryNotify
    vendor/github.com/cenkalti/backoff/retry.go:37
github.com/restic/restic/internal/backend.(*RetryBackend).retry
    internal/backend/backend_retry.go:36
github.com/restic/restic/internal/backend.(*RetryBackend).List
    internal/backend/backend_retry.go:126
github.com/restic/restic/internal/repository.(*Repository).List
    internal/repository/repository.go:634
github.com/restic/restic/internal/index.Load
    internal/index/index.go:202
main.pruneRepository
    cmd/restic/cmd_prune.go:202
main.runPrune
    cmd/restic/cmd_prune.go:128
main.glob..func18
    cmd/restic/cmd_prune.go:28
github.com/spf13/cobra.(*Command).execute
    vendor/github.com/spf13/cobra/command.go:762
github.com/spf13/cobra.(*Command).ExecuteC
    vendor/github.com/spf13/cobra/command.go:852
github.com/spf13/cobra.(*Command).Execute
    vendor/github.com/spf13/cobra/command.go:800
main.main
    cmd/restic/main.go:86
runtime.main
    /snap/go/3947/src/runtime/proc.go:200
runtime.goexit
    /snap/go/3947/src/runtime/asm_amd64.s:1337

@antetna Es sieht so aus, als hätte Ihr Repository mehrere Indexdateien, die dieselben Pakete abdecken. Ich weiß nicht, wie das passieren kann, aber ich habe der Testsuite einen Testfall dafür hinzugefügt, und ich kann Ihren Fehler reproduzieren. Ich werde daran arbeiten, es zu beheben.

@antetna OK, ich habe gerade eine neue Version in denselben Zweig geschoben (nicht im Schnellvorlauf), die mit meinem Testfall für doppelte Indizes funktioniert. Könnten Sie es versuchen?

Ich plane, bald einen Pull-Request mit der aktuellen Version dieses Zweigs zu öffnen, es sei denn, jemand anderes bemerkt irgendwelche Probleme.

Vielen Dank @cbane! Die Standardbereinigung dauerte etwa 55 Stunden, um mein ~860 GB 12000+ Snapshot-Repo zu beschneiden. Mit Ihrem aggressiveren parallelen Ansatz sank es auf etwas mehr als 3 Stunden.

Hallo @cbane , tolle Arbeit!

Wenn Sie diese PR hier auf Debian 9 amd64 ausführen, kompiliert mit Go 1.12.1, wird nach 220 Minuten auf meinem 30-TB-Repo die folgende Fehlermeldung angezeigt:

checking for packs not in index
[0:52] 16.45%  178 / 1082 packs
[5:23] 100.00%  1082 / 1082 packs
repository contains 3213929 packs (259446787 blobs) with 15.025 TiB
processed 259446787 blobs: 30090 duplicate blobs, 4.906 GiB duplicate
load all snapshots
find data that is still in use for 3 snapshots
[0:04] 0.00%  0 / 3 snapshots
tree 6f144a19eaae0e81518b396bfdfc9dd5c6c035bdba28c6a90d6f70e692aa1c55 not found in repository
github.com/restic/restic/internal/repository.(*Repository).LoadTree
        internal/repository/repository.go:707
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:52
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:74
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:74
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:74
github.com/restic/restic/internal/restic.FindUsedBlobs.func4
        internal/restic/find.go:89
gopkg.in/tomb%2ev2.(*Tomb).run
        vendor/gopkg.in/tomb.v2/tomb.go:163
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:1337

Wie soll ich mich davon erholen?

Danke,
- Durval.

@DurvalMenezes Es sieht so aus, als ob Ihrem Repository einige Pack-Dateien fehlen. Hast du es schon mal geschnitten? Ist restic check erfolgreich? Wenn dies nicht der Fall ist, sollte es Ihnen eine detailliertere Vorstellung davon geben, was falsch ist.

Möglicherweise können Sie sich etwas erholen, indem Sie restic rebuild-index und dann eine neue Sicherung ausführen. Wenn noch etwas in den fehlenden Paketen am gesicherten Speicherort verfügbar ist, wird es durch ein neues Backup wieder dem Repository hinzugefügt. Dadurch könnten Ihre vorhandenen Sicherungen wieder funktionieren. Wenn das nicht hilft, denke ich, dass Sie die betroffenen Snapshots vergessen müssen, bevor Sie eine Bereinigung vornehmen können.

Danke für die Antwort, @cbane. Mehr unten:

Hast du es schon mal geschnitten?

Nein, das ist meine erste Pflaume. Lange Rede, kurzer Sinn: Mein Repo hat ~95 Schnappschüsse von 3 lokalen Dirtrees auf meinem NAS; Diese 3 Dirtrees haben insgesamt ~30 TB und ~60 Millionen Dateien/Unterverzeichnisse, und die Sicherung dauerte immer länger, bis zu dem Punkt, dass die Sicherung von nur 24 Stunden neuer Daten (unter 10 GB) über 24 Stunden dauerte. Der Rat im Forum war, restic forget auszuführen (was ich getan habe, wobei nur die letzten 3 Snapshots übrig blieben) und dann restic prune , was ich zuerst mit restic 0.9.5 getan habe (aber es wurde nach ~ 24 Stunden wegen OOM). Ich habe dann die Maschine (eine VM in Google Compute Cloud) auf doppelt so viel RAM aktualisiert und dann Ihre PR verwendet, die den obigen Fehler ergab.

Ist restic check erfolgreich? Wenn dies nicht der Fall ist, sollte es Ihnen eine detailliertere Vorstellung davon geben, was falsch ist.

Ich habe restic check in den letzten 90 Stunden ausgeführt (auch mit Ihrem PR), und es hat mir bisher diese Ausgabe gegeben: restic-check-PARTIAL_output.txt

Wie am Ende der obigen Datei angemerkt, hat restic check vor über 3 Tagen seine letzte Meldung ("Überprüfe Snapshots, Bäume und Blobs") angezeigt... Ich wundere mich langsam, dass es hängen bleibt und niemals fertig wird :-/ Tatsächlich zeigt ein "strace" des Prozesses, dass er immer wieder dieselbe lokale Cache-Datei öffnet:

```Datum; strace -t -f -p 2608 -e openat 2>&1 | grep openat | egrep -v unfertig\|fortgesetzt | Kopf
Dienstag, 23. Juli 00:41:59 UTC 2019
[Pid 26508] 00.41.59 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2608] 00.41.59 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 10
[Pid 2615] 00.41.59 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 5482] 00.41.59 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2615] 00.41.59 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 3688] 00.41.59 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 5482] 00.41.59 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 10
[Pid 2608] 00.41.59 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 11
[Pid 2638] 00.41.59 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2638] 00.41.59 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5

And then, almost 10 hours later: 

Dienstag, 23. Juli 10:14:27 UTC 2019
[Pid 2632] 10.14.27 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2639] 10.14.28 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2634] 10.14.28 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2613] 10.14.28 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2634] 10.14.28 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 3688] 10.14.28 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2617] 10.14.28 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 3688] 10.14.28 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2634] 10.14.28 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2611] 10.14.28 openat (AT_FDCWD "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
```

Möglicherweise können Sie sich etwas erholen, indem Sie restic rebuild-index ausführen und dann eine neue Sicherung ausführen. Wenn noch etwas in den fehlenden Paketen am gesicherten Speicherort verfügbar ist, wird es durch ein neues Backup wieder dem Repository hinzugefügt. Dadurch könnten Ihre vorhandenen Sicherungen wieder funktionieren

Ich denke, ich werde das als nächstes versuchen; wenn dieses restic check nicht in den nächsten 24 Stunden beendet wird, werde ich es SIGINT und dann ein restic rebuild-index ausführen. Soll ich für den Rebuild-Index diesen PR verwenden? Der Restic-Master-Kopf? Oder etwas anderes?

Danke noch einmal,
- Durval.

Ja, das sieht nicht vielversprechend aus. Wahrscheinlich ist es am besten, ein restic rebuild-index zu machen, dann neue Backups Ihrer drei Verzeichnisse auszuführen und dann alle anderen Snapshots zu vergessen. Danach sollten Sie in der Lage sein, restic prune erfolgreich auszuführen.

Ich habe den Code rebuild-index nicht angerührt, also können Sie das mit jeder beliebigen Version tun.

@cbane , nur um Sie auf dem Laufenden zu halten: Ich habe vor 5 Tagen mit Ihrem PR ein restic rebuild-index gestartet (ich verstehe, dass jede Version ausreichen würde, aber die Verwendung Ihrer macht die Dinge einfacher) und seitdem läuft es. Nach den ersten verzweifelten Tagen (als die Extrapolation der Prozentsätze darauf hindeutete, dass es über 30 Tage laufen würde), scheint es etwas Fahrt aufgenommen zu haben und sollte "nur" noch etwa 10 Tage laufen (zumindest in seiner jetzigen 'Zählen von Dateien im Repo'-Phase).

Unter der Annahme, dass dieses rebuild-index OK endet, besteht der Plan darin, mit Ihrem PR ein restic prune zu fahren. Werde berichten wie es weitergeht.

Alle auf dem Laufenden halten: Mein kostenloses GCloud-Guthaben von 300 $ endete, völlig verschlungen von der 104-GB-VM, die ich erstellen musste, um die prune (und ich nehme an, auch die rebuild-index ) auszuführen. Mir gehen die Optionen aus :-/ Wird aktualisiert, wenn/falls ich einen Ausweg aus diesem Schlamassel finde.

Ich habe den Zweig "prune-speedup" ausprobiert und die Ergebnisse sind sehr vielversprechend!

Backend: S3

# bin/restic version
restic 0.9.5 compiled with go1.12.4 on linux/amd64
# bin/restic prune
repository 6240cd5d opened successfully, password is correct
counting files in repo
building new index for repo
[1:30:34] 100.00%  319784 / 319784 packs
repository contains 319784 packs (5554019 blobs) with 1.445 TiB
processed 5554019 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 30 snapshots
[3:38:52] 100.00%  30 / 30 snapshots
found 5376708 of 5554019 data blobs still in use, removing 177311 blobs
will remove 0 invalid files
will delete 3526 packs and rewrite 4850 packs, this frees 26.925 GiB
[1:28:21] 100.00%  4850 / 4850 packs rewritten
counting files in repo
[1:20:27] 100.00%  314240 / 314240 packs
finding old index files
saved new indexes as [b7029105 797145b1 0ed8981e 7f19c455 dff4d9be a52d8e7a 0cf9f266 ab32a9e4 f34331b3 84c84cbb 563896c9 9902e35d 817ef96c 6b4dcfef 32d3e18c 1d782d96 b12554dd d4b69bcf 8ec94a43 66cbd035 8e9cb96d d74b5246 ca7d7ca3 1f209708 9fe26189 28414ee2 88ff07fb 24280466 8757a1f9 8706ff35 5fab942b 549409c3 f781a762 9417afec 4b2361aa 6b43f992 8da8dfe7 54ec498e 5be6fb8a 17411b83 270f3ce3 ba520d35 95913ad0 f8f15108 cbc67971 a419ff7c 875cfcc7 13f55ece bd488aa4 7f5b588a cddd40b4 7a79d1ce bd7e3d0f 2cdcd635 ee6e28c3 98146287 50867bde 41a056ae 836ce971 e9451c8b 0f9cc7e6 52dedc04 c4e8e7f6 2e4966f0 ba4fa5b3 ddc9a766 b995fd36 fd6b3ac8 1c12bcc3 4c98c3c9 39ac7cd5 42ebf4c1 1a48465e b5245192 73a73c5e daa6ee8d d26ce697 9f84d9b3 bc371def b141466a 6906b3c1 282ce115 d8024363 10f0b924 ad4fad64 9450aada 31378365 65d785b3 98b085d0 768f420c f22512b3 be3223ba 031d5488 f2b7fcf6 87177471 fd269664 b239b89e 6bf972ea 0d6f8f36 87362542 fff9c2cd 5c85ac76 f91daae1 dc594a83 220bdc83]
remove 1459 old index files
[2:33] 100.00%  8376 / 8376 packs deleted
done
# 

Jetzt mit Dev-Version:

# bin/restic_linux_amd64 version
restic 0.9.5-dev (compiled manually) compiled with go1.12.4 on linux/amd64
# bin/restic_linux_amd64 prune
repository 6240cd5d opened successfully, password is correct
counting files in repo
building new index for repo
[57:21] 100.00%  314240 / 314240 packs
repository contains 314240 packs (5376708 blobs) with 1.419 TiB
processed 5376708 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 29 snapshots
[1:48:18] 100.00%  29 / 29 snapshots
found 5356653 of 5376708 data blobs still in use, removing 20055 blobs
will remove 0 invalid files
will delete 212 packs and rewrite 1427 packs, this frees 3.114 GiB
[14:16] 100.00%  1427 / 1427 packs rewritten
counting files in repo
[57:47] 100.00%  313618 / 313618 packs
finding old index files
saved new indexes as [004d6eb2 630de131 1b85faed 0fb7a978 bc500e05 34f7d187 447c3b59 ada047d2 5430430e 768f606e a5c341ea a75059c5 71d0fbec c63f5c56 ba43e69d f47699f5 d7cd2587 5826bcae 6250ec67 6af77aa4 cbf8c1f9 a7809b5f c3242748 8bb7d037 8ca69481 5a8877c3 fb30ea48 4bdb6269 eeeba466 7cdc444a bc15ddd5 c5544612 b8a5004c 2879403a c33778b7 e692013a 41ce8a1d 55b4be0a 5714b820 1adca569 b06ccd6b 16467da7 79ed066a 64c7e397 43217ede af7350a4 73c65a0f 35260990 a232ea42 c843bfa5 332aded7 0e294517 26984755 3c36a14b 68b2024e 267bf0b2 a41c4f64 aa46affb c7a6e2ac 0d34c60f 766d21f0 0d7b8b41 4fea4363 a1a3c5cd 73809a0e 56a67410 25314d47 a32ded24 68feae36 78ef5cbb b051a740 6a51f900 d2ee860f 1ad44787 c6c4358d 89de2f69 a157bd2b 77995b94 3bc58934 b905be42 0a1df2e7 ba67a98c 263b5266 7a809abc 34ff6f07 d96adc12 8f69fc74 ebb053eb 8fb68f6a 11224e7d 990f61f8 764941fc ed95513b 1c17c8aa 3226a7cb 76988c78 e4d8f156 b4d4c952 8c379d51 e968f3c9 f9cfff55 464cf3e1 f9d23c32 136957e3 02e397b1]
remove 105 old index files
[0:32] 100.00%  1639 / 1639 packs deleted
done
#

Es sieht nach einer großen Verbesserung aus! Glückwunsch!
Ich werde weitere Ergebnisse veröffentlichen, wenn ich in den kommenden Wochen weitere Maschinen anprobiere.

@fbarbeira Aus der von Ihnen geposteten Ausgabe geht hervor, dass Sie meine verbesserte Version nicht wirklich verwenden. Hier ist die Ausgabe, die ich bekomme, wenn ich mein großes Repository auf Backblaze B2 beschneide:

repository 399dfab1 opened successfully, password is correct
listing files in repo
loading index for repo
[0:02] 100.00%  71 / 71 index files
checking for packs not in index
repository contains 208840 packs (1675252 blobs) with 1006.203 GiB
processed 1675252 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 32 snapshots
[0:16] 100.00%  32 / 32 snapshots
found 1675113 of 1675252 data blobs still in use, removing 139 blobs
will remove 0 invalid files
will delete 4 packs and rewrite 24 packs, this frees 26.404 MiB
[3:31] 100.00%  24 / 24 packs rewritten
saving new index
[10:31] 70 index files
remove 71 old index files
[0:04] 100.00%  28 / 28 packs deleted
done

Die Hauptquelle der Langsamkeit dabei ist die begrenzte Upload-Geschwindigkeit über mein Kabelmodem.

Die Ausgabe von restic version sollte auch etwa so aussehen:

restic 0.9.5 (v0.9.5-31-g09b92d6d) compiled with go1.11.6 on linux/amd64

Irgendwelche Absichten, dieses Update @fd0 zusammenzuführen ?

Ich würde es sehr begrüßen, wenn diese Verbesserung auch zu einer offiziellen Version werden würde. Die Backup-Rotation ist so langsam geworden, dass Restic leider keine Option mehr ist.

@cbane , ein Element, das definitiv kein Blocker ist, aber ich dachte, ich würde markieren: Prune Pack Rewrites werden langsamer, wenn Repos wachsen.

Zum Beispiel schreibt der Paketumschreibungsschritt für ein Repository mit 3.984.097 Paketen Pakete mit 110 Paketen/Sekunde auf einem i3.8xlarge um und spricht mit einem S3-Bucket in derselben AZ.

Dieselbe Kombination aus Instanz und Backing Store mit einem kleineren Repo (450.473) schreibt mit 200 Packs/Sekunde um.

@pmkane , gibt es dort Geschwindigkeitsunterschiede, selbst wenn sie die gleiche Anzahl von Paketen neu schreiben? Oder ist es immer da, egal wie viele Pakete umgeschrieben werden? Ist es auch nur das Umschreiben des Packs oder verlangsamen sich auch andere Phasen?

Es gibt nichts Offensichtliches im Code, das ihn verlangsamen würde, wenn das Repository größer wird. Ich habe in meiner lokalen Version Profiling-Unterstützung zur Pack-Rewrite-Phase hinzugefügt, um dabei zu helfen, die Quelle der Langsamkeit aufzuspüren. Mein größtes Repository umfasst jedoch nur etwa 200.000 Packungen, was mir keinen guten Vergleich für das gibt, was Sie sehen. Wären Sie bereit, es mit aktivierter Profilerstellung auszuführen und die Ausgabedateien verfügbar zu machen?

@cbane , nicht sicher, ob es eine Funktion der Anzahl der Packs oder der Repo-Größe ist. Ich kann einige Tests auf einem Duplikat unseres kleineren Repos durchführen und sehen. Ich freue mich, eine Version mit Profilerstellung auszuführen und die Ergebnisse zu teilen.

Einige Beispiel-Timings für das 460k-Pack-Repo – 3,7-mm-Timings folgen:

Ladeindex für Repo
[0:01] 100,00 % 154 / 154 Indexdateien

finden Sie Daten, die noch für 36 Snapshots verwendet werden
[0:34] 100.00% 36 / 36 Schnappschüsse
[0:26] 100,00 % 4555 / 4555 Packs umgeschrieben (175 Packs/Sekunde)
[0:21] 151 Indexdateien
[0:01] 100.00% 11401 / 11401 Packs gelöscht

3.752.505 Pack-Repo. Es ist auch erwähnenswert, dass die Speichernutzung im Schritt "Daten finden, die noch für 14 Snapshots verwendet werden" von ~ 1 GB RSS auf 8 GB RSS ansteigt. Restic endet schließlich bei ~16 GB RSS. Angesichts der großen Repo-Größe vielleicht unvermeidlich:

Ladeindex für Repo
[0:33] 100,00 % 1188 / 1188 Indexdateien

finden Sie Daten, die noch für 14 Snapshots verwendet werden
[2:12] 100.00% 14 / 14 Schnappschüsse
[49:07] 100.00% 339187 / 339187 Packs umgeschrieben (115 Packs/Sekunde)
neuen Index speichern
[10:59] 1176 Indexdateien
Entfernen Sie 1188 alte Indexdateien
[4:51] 100.00% 409728 / 409728 Pakete gelöscht

@cbane , ich entschuldige mich. Ablenkungsmanöver bei den Schnittgeschwindigkeiten -- als ich ein unabhängiges Profil erstellte, stellte ich fest, dass sich die beiden Repos in verschiedenen AZs befanden, sodass der Unterschied ausschließlich auf die unterschiedliche Latenzzeit zu der weiter entfernten AZ zurückzuführen war.

In unserem großen Repo (20,791 TiB, 40.522.693 Blobs) erhalten wir beim Pruning im Schritt „Daten finden, die noch verwendet werden“ den folgenden Fehler:

Baum 5e40b6de93549df6443f55f0f68f24bf36671e28590579c78bc62f7557490c56 nicht im Repository gefunden
github.com/restic/restic/internal/repository.(Repository).LoadTreeinternal/repository/repository.go:711github.com/restic/restic/internal/restic.FindUsedBlobs.func3internal/restic/find.go:52github.com/restic/restic/internal/restic.FindUsedBlobs.func3internal/restic/find.go:74github.com/restic/restic/internal/restic.FindUsedBlobs.func4internal/restic/find.go:89gopkg.in/tomb%2ev2.( Tomb).run
Anbieter/gopkg.in/tomb.v2/tomb.go:163
runtime.goexit
/usr/lib/golang/src/runtime/asm_amd64.s:1337

Alle Sicherungen wurden erfolgreich abgeschlossen und eine Restic-Prüfung gibt keine Fehler zurück.

Irgendwelche zusätzlichen Grabungen, die es wert sind, hier getan zu werden, @cbane ?

Ein Rebuild-Index ermöglichte die erfolgreiche Beschneidung. Ich bin mir nicht sicher, ob es eine gute Möglichkeit gibt, Prune widerstandsfähiger zu machen, also könnte es das Problem nativ lösen.

Hmm, heute wieder der gleiche Fehler. Gelöst mit einem Rebuild-Index, aber ich frage mich langsam, ob die Beschneidung selbst das Problem verursachen könnte. Eine Restic-Prüfung kommt jedes Mal sauber zurück.

Baum 7dc9112b587a2b67a2459e6badf7c14f986408e05dbe8a68e7458a30740ea951 nicht im Repository gefunden
github.com/restic/restic/internal/repository.(Repository).LoadTreeinternal/repository/repository.go:711github.com/restic/restic/internal/restic.FindUsedBlobs.func3internal/restic/find.go:52github.com/restic/restic/internal/restic.FindUsedBlobs.func3internal/restic/find.go:74github.com/restic/restic/internal/restic.FindUsedBlobs.func4internal/restic/find.go:89gopkg.in/tomb%2ev2.( Tomb).run
Anbieter/gopkg.in/tomb.v2/tomb.go:163
runtime.goexit
/usr/lib/golang/src/runtime/asm_amd64.s:1337

Wir führen einmal pro Woche vollständige Wiederherstellungen durch, um die Integrität der Sicherung zu überprüfen und die täglichen Spot-Dateiwiederherstellungen zu ergänzen.

Während Restic Check keine Probleme mit der Sicherung zeigte, schlagen vollständige Wiederherstellungen aufgrund eines fehlenden Blobs fehl. Es sieht also so aus, als wäre etwas auf dem Weg beschnitten worden, was nicht hätte sein sollen.

Unklar, ob es sich um einen Fehler im Beschleunigungszweig, etwas im Basis-Prune-Code oder etwas ganz anderes handelt. Ich habe leider keinen großartigen reproduzierbaren Testfall, aber dies ist das zweite Mal, dass wir diese Art von Repo-Korruption bei unserem größten Repo sehen. Unsere kleineren Repos haben keine Probleme gezeigt.

Leider ist das Testen mit Stock-Prune aufgrund der Größe der Repos nicht möglich.

Wir werden vorerst auf EBS-Snapshots zurückgreifen, aber dieses und andere Problem weiterhin beobachten und gerne testen, wo es sinnvoll ist!

Ich habe eine kleine PR #2507 hinzugefügt, die die Situation verbessern sollte. Ich würde mich freuen, wenn einige von euch einige Tests dazu durchführen könnten ...
Danke!

Durchlesen des Prune-Codes - Repacking liest Blobs und speichert dann neue Packs seriell. Wenn Sie über das Netzwerk umpacken, wird dies der Engpass sein.

@DurvalMenezes ist Ihr NAS im lokalen Netzwerk oder über das Internet? Wenn Sie sich im lokalen Netzwerk über WLAN oder Ethernet verbinden?

Es scheint, als wäre es ein einfacher Gewinn, das Lesen von Blobs / Speichern von Paketen im Netzwerk zu parallelisieren.

Unabhängig davon frage ich mich, ob es eine bessere Strategie wäre, stattdessen zu versuchen, die Beschneidung inkrementell zu machen. So etwas wie die zweistufige Fossiliensammlung von Duplicacy: https://github.com/gilbertchen/duplicacy/wiki/Lock-Free-Deduplication#two -step-fossil-collection

Unabhängig davon frage ich mich, ob es eine bessere Strategie wäre, stattdessen zu versuchen, die Beschneidung inkrementell zu machen. So etwas wie die zweistufige Fossiliensammlung von Duplicacy: https://github.com/gilbertchen/duplicacy/wiki/Lock-Free-Deduplication#two -step-fossil-collection

Siehe Nr. 1141 für eine Diskussion zu diesem Thema.

Auch die beiden neuen Befehle 'cleanup-index' und 'cleanup-packs' aus PR #2513 sollten die Situation deutlich verbessern. Mit diesen Befehlen können Sie eine Beschneidung ohne Umpacken durchführen, wenn Ihr Repo in Ordnung ist.

Also habe ich versehentlich zwei Dinge getan, ich habe eine stündliche Sicherung 11 Mal pro Stunde statt 1 ausgeführt, und ich habe meinen Vergessen-Job in den letzten 384 Tagen oder so nicht ausgeführt. Ich habe 101417 Schnappschüsse. Ich dachte, es wäre zu langsam, dies zu vergessen / zu beschneiden, ich denke, ich werde es einfach löschen.

Sie können #2718 ausprobieren - es gibt jedoch keine Verbesserung für das "Vergessen" von Schnappschüssen.
Wenn der Vergessensschritt Ihr Problem ist, würde ich Ihnen raten:

• Finden Sie heraus, welche Snapshots Sie behalten möchten, zB indem Sie in Ihren letzten Backup-Protokollen nachsehen oder einfach ein weiteres Backup erstellen.
• Löschen Sie alle außer diesen Dateien manuell aus dem /snapshots -Verzeichnis Ihres Repositorys
• Führen Sie danach prune aus (wenn Sie möchten, mit #2718)

Ich wollte sie nur ein paar Tage behalten, also lösche ich einfach das gesamte Verzeichnis auf S3 und fange von vorne an. Ich habe den Vergessensprozess gestartet und es hat sehr lange gedauert, ich dachte, entweder würde der neuere Zweig helfen (sieht nicht danach aus), oder zumindest könnte es jemand amüsant finden.

Ich möchte diesen Zweig wirklich ausprobieren (oder wünschte wirklich, er wäre in den Master gezogen worden). Ich habe versucht zu testen und zu bekommen

Schwerwiegend: Konfigurationsdatei kann nicht geöffnet werden: Statistik: Die von Ihnen angegebene AWS-Zugriffsschlüssel-ID existiert nicht in unseren Aufzeichnungen.

Funktioniert ohne Probleme mit dem Master-Build. Ich konnte auch den Zweig unter https://github.com/restic/restic/pull/2340 ohne Probleme verwenden.

Ich kann diesen Zweig in einem NFS-gemounteten Repository verwenden, nur das von AWS gespeicherte Repository ist nicht funktionsfähig. Ich habe keine Ahnung wie ich den Fehler beheben soll...

danke für all die gute Arbeit, unabhängig davon

@vtwaldo21 Welchen Zweig hast du ausprobiert? War es #2718?
Ihre Fehlermeldung weist darauf hin, dass Sie Probleme mit Ihren AWS-Anmeldeinformationen haben. Dies könnte auch erklären, warum NFS ohne Probleme funktioniert hat.

Funktionieren andere Restic-Befehle mit Ihrem AWS-Repository?

@aawsome , ich bin ein Idiot und habe die Zweig- / Ausgabenummern vertauscht und die Dinge wirklich verwirrt. Verzeihung.

Zweig 2718 funktionierte einwandfrei (sowohl auf AWS- als auch auf NFS-gestützten Repos). Ich kann nicht definitiv sagen, ob es schneller war oder nicht, da es immer noch läuft
Zweigstelle 2340, war derjenige mit dem Problem und warum ich in diesem Forenthread war.

Branch 2340 basiert auf 0.9.5, also etwas älter, aber nicht so schlimm. Ich habe einfache Tests wie folgt durchgeführt:

Restic Binary ist Pfad wird gerade über RPM (0.9.6) installiert

restische Momentaufnahmen
[funktioniert]
restic.2718/restic Schnappschüsse
[funktioniert]
restic.2340/restic-Snapshots
Schwerwiegend: Konfigurationsdatei kann nicht geöffnet werden: Statistik: Die von Ihnen angegebene AWS-Zugriffsschlüssel-ID existiert nicht in unseren Aufzeichnungen.

Während der Fehler also etwas mit AWS-Anmeldeinformationen impliziert, führe ich die Befehle buchstäblich Rücken an Rücken ohne Variablenänderungen aus. Es scheint, dass mit diesem Zweig etwas anderes nicht stimmt.

Meine Pflaumen brauchen Tage für ein Repo von ~ 2 TB, daher bin ich sehr daran interessiert, dass sowohl 2718 als auch 2340 in Master zusammengeführt werden

@cbane vielen Dank für all deine Arbeit! Wir haben gerade #2718 zusammengeführt, das den Prune-Code überarbeitet, und ich denke, es löst dieses Problem ebenso wie #2340.

Es tut mir sehr leid, wie wir mit Ihrem Beitrag umgegangen sind. Ich hoffe, Sie können meine Entschuldigung annehmen. :enttäuscht:

Ich habe mit @MichaelEischer gesprochen, er erwähnte, dass die PR Nr. 2340 weitere Ideen enthält, die noch nicht umgesetzt wurden, also eröffne ich diese Ausgabe erneut.

@cbane Sind Sie daran interessiert, mit uns zusammenzuarbeiten, um diese Ideen in den aktuellen Code einzufügen? Ich kann es vollkommen verstehen, wenn nicht, dann gehen wir Ihre PR durch und extrahieren sie selbst :)

Wir hatten gestern auch eine kurze Diskussion und versuchten herauszufinden, was schief gelaufen sein könnte, damit wir es beim nächsten Mal besser machen können. Einige Punkte, die wir identifiziert haben, waren:

• Die PR hat einen hochsensiblen Bereich im Code geändert (Prune, wodurch letztendlich Daten entfernt werden), sodass eine zusätzliche Überprüfung erforderlich ist
• Sowohl @MichaelEischer als auch @aawsome versuchten, die PR zu überprüfen und sagten, sie sei zu groß
• Der PR bestand nur aus zwei Commits, einer davon ersetzte den gesamten Code durch anderen, völlig anderen Code, das ist sehr schwer zu überprüfen
• Die PR enthielt mindestens 4-5 verschiedene Ideen und Verbesserungen, was die Überprüfung noch schwieriger macht

Irgendwelche anderen Dinge, die ich verpasst habe?

Die Änderungen an cmd_prune.go von #2340 sind, soweit ich sehen kann, vollständig durch #2718 und #2842 von @aawsome ersetzt worden. #3006 ersetzt auch die index/index.go-Änderungen.

Ich habe die hochgradig parallelisierte Tree-Walking-Implementierung aus checker.go extrahiert (siehe https://github.com/MichaelEischer/restic/tree/streamtrees), die es ermöglicht, ein paralleles FindUsedBlobs mit ein paar zu implementieren zusätzliche Codezeilen. Es ist auch für den Kopierbefehl wiederverwendbar. Mein erwähnter Zweig vereinheitlicht auch den Code, der zum Parallelisieren des Index- und Snapshot-Ladens verwendet wird. Ich werde den Zweig in kleinere PRs aufteilen.

Dies scheint die Verwendung der Backend-Verbindungsanzahl und GOMAXPROCS zu verlassen, um sich automatisch an die IO/CPU-Parallelität als verbleibender Teil von #2340 anzupassen.

Mir ist aufgefallen, dass weder #2340 noch der andere Prune-PR derzeit den Upload des umgeschriebenen Indexes parallelisieren.