s3cmd schlägt zu oft fehl

7

Früher war es mein bevorzugter Backup-Transport-Agent, jetzt erhalte ich dieses Ergebnis häufig von s3cmd auf demselben Ubuntu-Server / Netzwerk:

root@server:/home/backups# s3cmd put bkup.tgz s3://mybucket/
bkup.tgz -> s3://mybucket/bkup.tgz  [1 of 1]
      36864 of 2711541519     0% in    1s    20.95 kB/s  failed
WARNING: Upload failed: /bkup.tgz ([Errno 32] Broken pipe)
WARNING: Retrying on lower speed (throttle=0.00)
WARNING: Waiting 3 sec...
bkup.tgz -> s3://mybucket/bkup.tgz  [1 of 1]
      36864 of 2711541519     0% in    1s    23.96 kB/s  failed
WARNING: Upload failed: /bkup.tgz ([Errno 32] Broken pipe)
WARNING: Retrying on lower speed (throttle=0.01)
WARNING: Waiting 6 sec...
bkup.tgz -> s3://mybucket/bkup.tgz  [1 of 1]
      28672 of 2711541519     0% in    1s    18.71 kB/s  failed
WARNING: Upload failed: /bkup.tgz ([Errno 32] Broken pipe)
WARNING: Retrying on lower speed (throttle=0.05)
WARNING: Waiting 9 sec...
bkup.tgz -> s3://mybucket/bkup.tgz  [1 of 1]
      28672 of 2711541519     0% in    1s    18.86 kB/s  failed
WARNING: Upload failed: /bkup.tgz ([Errno 32] Broken pipe)
WARNING: Retrying on lower speed (throttle=0.25)
WARNING: Waiting 12 sec...
bkup.tgz -> s3://mybucket/bkup.tgz  [1 of 1]
      28672 of 2711541519     0% in    1s    15.79 kB/s  failed
WARNING: Upload failed: /bkup.tgz ([Errno 32] Broken pipe)
WARNING: Retrying on lower speed (throttle=1.25)
WARNING: Waiting 15 sec...
bkup.tgz -> s3://mybucket/bkup.tgz  [1 of 1]
      12288 of 2711541519     0% in    2s     4.78 kB/s  failed
ERROR: Upload of 'bkup.tgz' failed too many times. Skipping that file.

Dies geschieht sogar bei Dateien mit einer Größe von nur 100 MB. Ich nehme an, es handelt sich nicht um ein Größenproblem. Es passiert auch, wenn ich put mit --acl-private flag (s3cmd Version 1.0.1) verwende.

Ich freue mich, wenn Sie eine Lösung oder eine leichte Alternative zu s3cmd vorschlagen.

linux backup amazon-s3 Alfish
quelle
Haben Sie s3cp ausprobiert ? Es sollte tun, was Sie wollen - ich glaube, es hat auch ausführlichere Fehlermeldungen. In Bezug auf den Fehler, den Sie erhalten, scheinen einige häufige Ursachen nicht vorhanden zu sein (z. B. falsch eingegebener Bucket-Name), nachgestellte Leerzeichen auf Ihren Authentifizierungswerten (Schlüssel / ID) oder eine ungenaue Systemuhr
cyberx86
@ cyberx86, ich zögere ein bisschen, auf s3cp umzusteigen, weil ich lieber vermeiden möchte, dass JVM nur zum Zweck der Dateikopie auf myserver sitzt. Wie Sie bemerkt haben, ist das Seltsame, dass s3cmd früher wie ein Zauber funktioniert hat.
Alfish
Abhängig von der Komplexität Ihrer Aufgaben ist es möglicherweise recht einfach, die Python-Botobibliothek zum Hochladen Ihrer Dateien in S3 zu verwenden. Sie sollten in der Lage sein, ein Beispiel dafür recht einfach zu finden. Ich glaube, es gibt sogar ein Projekt , um einige der Boto-Funktionen in einem Kommandozeilen-Tool verfügbar zu machen. Wenn Sie ein Perl-Skript möchten, ist Tim Kays aws sehr vielseitig und einfach zu bedienen - und sollte alles tun, was Sie wollen.
Cyberx86
@ cyberx86 Die 'aws' funktionierten nicht nur hervorragend beim Einfügen einer großen Datei, sondern gaben auch den Grund an, warum s3cmd nicht funktionierte. Es gab eine Warnung (Sanity-Check), dass die Systemuhr etwa 1700s voraus war. Als ich die Uhr einstellte, begann s3cmd wie zuvor zu arbeiten. Ich denke, das Problem mit s3cmd war, dass wenn sich der sendende Server und der S3-Host in derselben Zeitzone befinden, die Serverzeit nicht voraus sein sollte. Sie viele geben dies als Antwort und ich werde es akzeptieren. Vielen Dank
Alfish
Etwas niedrige Augenbrauenreaktion hier, aber ich hatte ein Backup-Skript (s3cmd), das über ein Jahr lang unberührt war ... ging wie oben durcheinander und nachdem ich hier einen Vorschlag gemacht hatte, hatten sich die Berechtigungen für meinen S3-Bucket "magisch" geändert ... seltsam.

Antworten:

7

Es gibt einige häufige Probleme, die dazu führen, dass s3cmd den von Ihnen erwähnten Fehler zurückgibt:

  • Ein nicht vorhandener (z. B. falsch eingegebener Bucket-Name oder ein Bucket, der noch nicht bereitgestellt wurde)
  • Nachgestellte Leerzeichen in Ihren Authentifizierungswerten (Schlüssel / ID)
  • Eine ungenaue Systemuhr. Es ist möglich, Wireshark (über eine http - nicht https - Verbindung) zu verwenden, um zu sehen, wie Ihre Systemuhr mit der Uhr von S3 übereinstimmt - sie sollte innerhalb weniger Sekunden übereinstimmen. Verwenden Sie NTP, um Ihre Uhr zu synchronisieren, wenn dies ein Problem darstellt.

Alternativen zu s3cmd:

  • s3cp - ein Java-basiertes Skript, das gute Funktionen zum Übertragen von Dateien nach S3 und ausführlichere Fehlermeldungen als s3cmd bietet
  • aws - ein Perl-basiertes Skript, das von Tim Kay geschrieben wurde und einfachen Zugriff auf die meisten AWS-Funktionen (einschließlich S3) bietet und sehr beliebt ist.

Wenn Sie Ihr eigenes Skript schreiben möchten, können Sie die Python Boto-Bibliothek verwenden, die Funktionen zum Ausführen der meisten AWS-Vorgänge enthält und über viele Beispiele online verfügt. Es gibt ein Projekt , das einige der Boto-Funktionen in der Befehlszeile verfügbar macht - obwohl derzeit nur sehr wenige Funktionen verfügbar sind.

cyberx86
quelle
1
In meinem Fall war das Problem auf die ungenaue Systemuhr zurückzuführen. Schätzen Sie wirklich Ihre Hinweise.
Alfish
Vielen Dank. Ich hatte das gleiche Problem. Die Uhr sah richtig aus und ich konnte kleine Dateien hochladen, also glaube ich nicht, dass es die anderen Vorschläge waren. Hat aber awsperfekt funktioniert.
Darren Cook
14

Dies hat in meinem Fall geholfen:

  1. s3cmd lsauf dem Eimer tun
  2. Es wurde eine Warnung über eine Umleitung gedruckt
  3. Ersetzen Sie das bucket_hostin der .s3cfgDatei durch das aus der Warnung.
  4. Wiederholen s3cmd ls, es sollte keine Warnung mehr gedruckt werden
  5. Datei erneut hochladen

meine .s3cfg ist jetzt:

host_bucket = %(bucket)s.s3-external-3.amazonaws.com
reto
quelle
Ich habe das host_bucket durch meinen Bucket-Hostnamen ersetzt (wie Bucketname.s3-sa-east-1.amazonaws.com).
Rafael Kassner
Wir hatten das gleiche Problem; viel Zeit für Antworten; fand dies unabhängig heraus und es scheint zu funktionieren (Daumen drücken).
user3546411
Wir haben festgestellt, dass das Argument --region in einigen Fällen ebenfalls erforderlich ist. Wir verwenden jetzt sowohl den Konfigurationseintrag host_bucket als auch das Befehlszeilenargument --region. Bisher scheint dies zu funktionieren.
user3546411
1

Nachdem ich alle oben genannten Dinge ausprobiert hatte, bemerkte ich, dass ich immer noch das Problem der Drosselung mit s3cmd put habe, aber stattdessen nicht mit s3cmd sync. Hoffe, dies könnte jemandem für eine schnelle Lösung nützlich sein :)

Fabio Pedrazzoli
quelle
1

Ich hatte das gleiche Problem und eine Lösung gefunden , hier als Antwort von samwise .

Dieses Problem trat auf, als ich mit IAM experimentierte. In meinem Fall war das Problem in ARN. I aufgelistet arn:aws:s3:::bucketnamestattarn:aws:s3:::bucketname/*

Deshalb hatte ich keine Probleme mit $ s3cmd ls s: // Bucketname, konnte dort aber keine Datei hochladen ((

user221341
quelle
1

Ich hatte jeden zweiten Upload eines mehrteiligen Uploads s3cmd syncmit diesem Fehler fehlgeschlagen:

WARNING: Upload failed: /large-file.gz?partNumber=13&uploadId=FOOBAR ([Errno 32] Broken pipe)
WARNING: Retrying on lower speed (throttle=0.00)
WARNING: Waiting 3 sec...

Der nächste Upload würde großartig funktionieren, aber dann schlug einer erneut fehl und so weiter.

Ich habe es mit der --limit-rate=Option zum 4mLaufen gebracht , so dass Uploads auf höchstens 4 MB / s gedrosselt werden.

Die volle Einstellung ist also

s3cmd sync --limit-rate=4m ...
Jan Papenbrock
quelle
0

Dies wird auch häufig durch HTTPS-Einstellungen Ihrer .s3cfg-Datei verursacht.

Versuchen Sie, den Konfigurationsparameter in der .s3cfg von "use_https = False" in "use_https = True" zu ändern

Denken Sie daran, dass Amazon-Eimer zu HTTP weiterleiten und daher alle Wiederholungsversuche. Ich sehe dieses Problem ziemlich oft auf dem Gebiet.

Marchato
quelle