Vraag s3cmd mislukt te vaak


Het was mijn favoriete back-uptransportmiddel, maar nu krijg ik dit resultaat vaak van s3cmd op dezelfde Ubuntu-server / -netwerk:

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.

Dit gebeurt zelfs voor bestanden zo klein als 100 MB, dus ik neem aan dat het geen probleem met de grootte is. Het gebeurt ook als ik put gebruik met --acl-private flag (s3cmd versie 1.0.1)

Ik waardeer het als je een oplossing of een licht alternatief voor s3cmd voorstelt.


7
2017-11-12 23:41


oorsprong


Heb je geprobeerd s3cp? Het zou moeten doen wat je wilt - ik geloof dat het ook meer uitgebreide foutmeldingen heeft. Wat betreft de fout die u krijgt, lijken enkele veel voorkomende oorzaken een niet-bestaande (bijv. Verkeerd gespotte bucket-naam), trailing-spaties op uw authenticatiewaarden (sleutel / id) of een onjuiste systeemklok - cyberx86
@ cyberx86, ik ben een beetje terughoudend om over te schakelen naar s3cp omdat ik liever JVM op myserver zou mijden, alleen voor bestandskopiedoeleinden. Zoals je zag, is het bizarre dat s3cmd vroeger als een charme werkte. - alfish
Afhankelijk van de complexiteit van wat u wilt doen, kan het vrij eenvoudig zijn om de Python boto-bibliotheek te gebruiken om uw bestanden naar S3 te uploaden - u zou hier gemakkelijk een voorbeeld van kunnen vinden. Ik geloof dat er zelfs een is project om een ​​aantal van de boto-functies bloot te leggen in een opdrachtregelprogramma. Als je een Perl-script wilt, Tim Kay's aws is vrij veelzijdig en gemakkelijk te gebruiken - en zou alles moeten doen wat je wilt. - cyberx86
@ cyberx86 de 'aws' werkten niet alleen prima in het plaatsen van een groot bestand, maar gaven ook aan waarom s3cmd niet werkte. Het gaf een waarschuwing (sanity-check) dat de systeemklok ongeveer 1700 seconden vooruit was. Toen ik de klok aanpaste, begon s3cmd te werken zoals eerder. Dus ik denk dat het probleem met s3cmd was dat wanneer de verzendende server en de S3-host zich in dezelfde tijdzone bevinden, de servertijd niet voorop hoeft te liggen. Jullie velen noemen dit als een antwoord en ik zal het accepteren. Erg bedankt - alfish
Iets laag voorhoofdrespons hier maar Ik had een back-up script (s3cmd) werkend en onaangeroerd gedurende meer dan een jaar ... werd gestopt zoals hierboven en na het proberen van de suggestie hier ontdekte permissies had "magisch" veranderd op mijn S3 emmer ... raar.


antwoorden:


Er zijn een paar veelvoorkomende problemen die ertoe leiden dat s3cmd de fout retourneert die u noemt:

  • Een niet-bestaande (bijvoorbeeld verkeerd getypte bucket-naam of een bucket die nog niet is ingericht)
  • Trailing-spaties op uw authenticatiewaarden (sleutel / id)
  • Een onnauwkeurige systeemklok. Het is mogelijk om Wireshark te gebruiken (via een http - niet https-verbinding) om te zien hoe uw systeemklok overeenkomt met de klok van S3 - ze moeten binnen een paar seconden overeenkomen. Overweeg NTP te gebruiken om uw klok te synchroniseren als dit een probleem is.

Alternatieven voor s3cmd:

  • s3cp - een op Java gebaseerd script dat goede functionaliteit biedt voor het overbrengen van bestanden naar S3, en meer uitgebreide foutmeldingen dan s3cmd
  • aws - een op Perl gebaseerd script, geschreven door Tim Kay, dat gemakkelijke toegang biedt tot de meeste AWS (inclusief S3) functies, en vrij populair is.

Als u uw eigen script wilt schrijven, kunt u de Python Boto-bibliotheek gebruiken met functies voor het uitvoeren van de meeste AWS-bewerkingen en heeft u vele voorbeelden online beschikbaar. Er is een project die een aantal van de boto-functies op de opdrachtregel blootlegt - hoewel er momenteel een zeer kleine reeks functies beschikbaar is.


7
2017-11-13 19:22



In mijn geval was het probleem te wijten aan de onnauwkeurige systeemklok. Echt waarderen uw hints. - alfish
Bedankt. Ik had hetzelfde probleem. De klok zag er goed uit en ik kon kleine bestanden uploaden, dus ik denk niet dat het de andere suggesties waren. Echter aws werkte perfect. - Darren Cook
In mijn geval was het een ontbrekende emmer. Dank je - gakhov


Dit hielp in mijn geval:

  1. do s3cmd ls op de emmer
  2. het heeft een waarschuwing afgedrukt voor een omleiding
  3. vervang de bucket_host in de .s3cfg bestand met degene van de waarschuwing.
  4. herhaling s3cmd ls, het zou geen waarschuwing meer moeten afdrukken
  5. upload bestand opnieuw

mijn .s3cfg is nu:

host_bucket = %(bucket)s.s3-external-3.amazonaws.com

14
2018-02-21 11:04



Ik heb de host_bucket vervangen door mijn bucket-hostnaam (zoals bucketname.s3-sa-east-1.amazonaws.com). - Rafael Kassner
We hebben hetzelfde probleem gehad; veel tijd slepend voor antwoorden; bedacht dit onafhankelijk en het lijkt te werken (vingers gekruist). - user3546411
We hebben geconstateerd dat de - regio arg ook in sommige gevallen noodzakelijk is. We gebruiken nu het configuratiebestand host_bucket en de --region command line arg .. tot nu toe lijkt dit te werken. - user3546411


Ik had hetzelfde probleem met de Ubuntu s3cmd commando.

Het downloaden van de nieuwste stabiele versie (1.0.1) loste het op: http://sourceforge.net/projects/s3tools/files/s3cmd/


2
2018-03-19 13:24



Ik volgde instructies op s3tools.org/repositories#note-deb maar het hielp niet. (Echter s3cmd --version vertelt me ​​1.0.0, niet 1.0.1, zodat een klein versienummer belangrijk kan zijn; dit is op ubuntu 11.04) - Darren Cook


Na alle bovenstaande dingen te hebben geprobeerd, merkte ik dat ik nog steeds het probleem met de throttling ondervond door s3cmd te gebruiken, maar niet door s3cmd-sync te gebruiken. Ik hoop dat dit nuttig kan zijn voor iemand voor een snelle oplossing :)


1
2017-12-18 12:08





Ik had hetzelfde probleem en vond een oplossing hier in reactie van Samwise.

Dit probleem verscheen toen ik begon met experimenten met IAM. In mijn geval was het probleem in ARN. Ik vermeldde arn:aws:s3:::bucketname in plaats van arn:aws:s3:::bucketname/*

Daarom had ik geen problemen met $ s3cmd ls s: // bucketname, maar kon daar geen bestand uploaden ((


1
2018-06-26 08:51





Ik had elke seconde upload van multi-part upload met s3cmd sync mislukt met deze fout:

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...

De volgende upload zou geweldig werken, maar dan is er weer een mislukt, enzovoort.

Ik heb ermee gewerkt --limit-rate= optie ingesteld op 4m zodat uploads worden beperkt tot maximaal 4 MB / sec.

Dus volledige instelling is

s3cmd sync --limit-rate=4m ...

1
2017-09-02 06:44





Dit wordt ook vaak veroorzaakt door HTTPS-instellingen van uw .s3cfg-bestand.

Probeer de configuratieparameter van "use_https = False" in "use_https = True" in de .s3cfg te veranderen

Onthoud dat amazon-buckets doorverwijzen naar Https en dus alle nieuwe pogingen. Ik zie deze kwestie best een beetje in het veld.


0
2017-11-11 17:12