Aws-cli: A sincronização AWS S3 não sincroniza todos os arquivos

Você pode possivelmente usar --exact-timestamps para contornar isso, embora isso possa resultar em uploads em excesso se você estiver enviando.

Para ajudar na reprodução, você poderia me fornecer algumas informações sobre um dos arquivos que não está sincronizando?

• Qual é o tamanho exato do arquivo localmente?
• Qual é o tamanho exato do arquivo no S3?
• Qual é a última hora modificada localmente?
• Qual é a última hora modificada no S3?
• O arquivo local é um link simbólico / atrás de um link simbólico?

Exemplo de execução de comando
aws s3 sync s3: // bucket / / var / www / folder / --delete

Vários arquivos estão faltando
Tamanho local exato: 2625
S3 exato: 2625
Carimbo de hora local exato: 06 de janeiro de 2017, 9:32:31
Carimbo de hora exato s3: 20-Jun-2017 10:14:57
arquivo normal em S3 e local

Existem vários casos assim em uma lista de cerca de 50.000 arquivos. No entanto, todos os que faltam na sincronização ocorrem várias vezes em 20 de junho de 2017.

Usar --exact-timestamps mostra muito mais arquivos para baixar, embora tenham exatamente o mesmo conteúdo. No entanto, ainda faltam os do exemplo acima.

mesmo problema aqui.
aws s3 sync dist/ s3://bucket --delete não carregou s3: //bucket/index.html com dist / index.html

dist / index.html e s3: //bucket/index.html têm o mesmo tamanho de arquivo, mas seu tempo de modificação é diferente.

na verdade, algumas vezes awscli carregou o arquivo, mas outras vezes não

O mesmo aqui, --exact-timestamps não ajuda - index.html não é sobrescrito.

Experimentamos esse problema bem hoje / semana passada. Novamente, index.html tem o mesmo tamanho de arquivo, mas o conteúdo e os tempos de modificação são diferentes.

Alguém está ciente de uma solução alternativa para isso?

Eu apenas corri para isso. Mesmo problema relatado por @icymind e @samdammers : o conteúdo do meu arquivo (local) index.html mudou, mas o tamanho do arquivo era o mesmo da cópia anterior no S3. O comando {{aws s3 sync}} não fez o upload. Minha "solução alternativa" foi excluir index.html do S3 e, em seguida, executar a sincronização novamente (que então carregou como se fosse um novo arquivo, eu acho).

Servidor: EC2 linux
Versão: aws-cli/1.16.108 Python/2.7.15 Linux/4.9.62-21.56.amzn1.x86_64 botocore/1.12.98

Depois de aws s3 sync executar mais de 270T de dados, perdi alguns GB de arquivos. O Sync não copiou arquivos com caracteres especiais.

Exemplo de arquivo /data/company/storage/projects/1013815/3.Company Estimates/B. Estimates

Tive que usar cp -R -n

mesmo problema aqui, arquivo xml do mesmo tamanho, mas carimbo de data / hora diferente não sincronizado corretamente

Consegui reproduzir este problema

bug.tar.gz
baixe o arquivo tar anexado e então

tar -zxvf bug.tar.gz
aws s3 sync a/ s3://<some-bucket-name>/<some_dir>/ --delete
aws s3 sync b/ s3://<some-bucket-name>/<some_dir>/ --delete

você verá que, embora repomd.xml nos diretórios aeb difiram em conteúdo e carimbos de data / hora
tentar sincronizar b não faz nada

Testado em
aws-cli / 1.16.88 Python / 2.7.15 Darwin / 16.7.0 botocore / 1.12.78
aws-cli / 1.16.109 Python / 2.7.5 Linux / 3.10.0-693.17.1.el7.x86_64 botocore / 1.12.99

estou vendo o mesmo problema. tentando sincronizar um diretório de arquivos de s3 onde um arquivo foi atualizado para um diretório local. aquele arquivo não é atualizado no diretório local

Estou vendo isso também. No meu caso, é um aplicativo react com index.html que se refere a arquivos .js gerados. Estou sincronizando-os com a opção --delete para excluir arquivos antigos que não são mais referidos. Às vezes, o index.html não é carregado, resultando em um index.html antigo que aponta para arquivos .js que não existem mais.

Daí meu site parar de funcionar !!!

No momento, não tenho ideia de por que isso está acontecendo.

Alguém tem alguma ideia ou solução alternativa?

Temos o mesmo problema, mas acabamos de encontrar uma solução alternativa. Eu sei, não é a melhor forma, mas funciona:

aws s3 cp s3://SRC s3://DEST ...
aws s3 sync s3://SRC s3://DEST ... --delete

Parece-nos que a cópia está funcionando bem, então primeiro copiamos, depois usamos o comando sync para deletar arquivos, que não estão mais presentes.
Espero que o problema seja corrigido o mais rápido possível.

Eu adicionei --exact-timestamps ao meu pipeline e o problema não se repetiu. Mas, em primeiro lugar, era intermitente, por isso não posso ter a certeza de que o corrigiu. Se acontecer de novo, irei com a sugestão de @ marns93 .

Resolvemos esse problema e --exact-timestamps resolve nosso problema. Não tenho certeza se é exatamente o mesmo problema.

Estou vendo esse problema e é muito óbvio porque cada chamada precisa copiar apenas um punhado (menos de uma dúzia) de arquivos.

A situação em que isso acontece é exatamente como relatado acima: se a pasta sendo sync ed em contiver um arquivo com conteúdo de arquivo diferente, mas tamanho de arquivo idêntico, sync irá ignorar a cópia do novo arquivo atualizado de S3.

Acabamos alterando os scripts para aws s3 cp --recursive para consertá-lo, mas esse é um bug desagradável - por muito tempo pensamos que havia algum tipo de condição de corrida em nosso próprio aplicativo, sem perceber que o aws-cli era simplesmente optando por não copiar o (s) arquivo (s) atualizado (s).

Eu vi isso também com um arquivo html

aws-cli/1.16.168 Python/3.6.0 Windows/2012ServerR2 botocore/1.12.158

Eu copiei e colei o comando s3 sync de um gist GitHub e ele tinha --size-only definido nele. Remover isso resolveu o problema!

Acabei de encontrar esse problema com o upload de artefatos de compilação para um intervalo. Nosso HTML tendia a alterar apenas os códigos hash para links de ativos e, portanto, o tamanho era sempre o mesmo. A sincronização do S3 estava pulando isso se a compilação fosse logo após a anterior. Exemplo:

10:01 - Build 1 é executado
10:05 - Versão 2 é executado
10:06 - Build 1 carregado para s3
10:10 - Build 2 é carregado para s3

O Build 2 tem arquivos HTML com um carimbo de data / hora de 10:05, no entanto, os arquivos HTML carregados para s3 pelo build 1 têm um carimbo de data / hora de 10:06, pois é quando os objetos foram criados. Isso faz com que eles sejam ignorados pelo s3 sync, pois os arquivos remotos são "mais novos" do que os arquivos locais.

Agora estou usando s3 cp --recursive seguido de s3 sync --delete como sugerido anteriormente.

Espero que isso possa ser útil para alguém.

Eu tive o mesmo problema no início desta semana; Eu não estava usando --size-only . Nosso index.html era diferente por um único caractere ( . foi para # ), então o tamanho era o mesmo, mas o carimbo de data / hora em s3 era 40 minutos anterior ao carimbo de data / hora do novo índice .html. Excluí o index.html como uma solução temporária, mas é inviável verificar cada implantação.

O mesmo aqui, arquivos com o mesmo nome, mas com timestamp e conteúdo diferentes não são sincronizados do S3 para o local e --delete não ajuda

Nós experimentamos o mesmo problema. Um index.html com o mesmo tamanho, mas com um carimbo de data / hora mais recente, não é copiado.

Este problema foi relatado há mais de um ano. Por que não foi corrigido?

Na verdade, torna o comando snyc inútil.

tempo exato

--exact-timestamps corrigiu o problema

Eu também sou afetado por este problema. Eu adicionei --exact-timestamps e o problema parecia corrigir os arquivos que eu estava olhando. não fiz uma pesquisa exaustiva. Tenho cerca de 100k arquivos e 20 gb, muito menos do que os outros aqui.

Eu enfrentei o mesmo problema, aws s3 sync pular alguns arquivos, mesmo com conteúdos e datas diferentes. O log mostra que os arquivos ignorados são sincronizados, mas não são.
Mas quando executo aws s3 sync novamente, esses arquivos foram sincronizados. Muito estranho!

Tive esse problema ao construir um site com Hugo e finalmente descobri. Eu uso submódulos para o meu tema de Hugo e não os estava puxando para baixo no CI. Isso estava causando avisos em Hugo, mas não falhas.

# On local
                   | EN
-------------------+-----
  Pages            | 16
  Paginator pages  |  0
  Non-page files   |  0
  Static files     |  7
  Processed images |  0
  Aliases          |  7
  Sitemaps         |  1
  Cleaned          |  0

# On CI
                   | EN  
-------------------+-----
  Pages            |  7  
  Paginator pages  |  0  
  Non-page files   |  0  
  Static files     |  2  
  Processed images |  0  
  Aliases          |  0  
  Sitemaps         |  1  
  Cleaned          |  0  

Assim que atualizei os submódulos, tudo funcionou conforme o esperado.

Também fomos afetados por esse problema, tanto que uma plataforma ficou inativa por aproximadamente 18 horas depois que um novo arquivo vendor/autoload.php não sincronizou e estava desatualizado com vendor/composer/autoload_real.php todo o aplicativo não pode carregar.

Este é um problema _muito_ estranho e não posso acreditar que esteja aberto há tanto tempo.

Por que uma sincronização não usaria hashes em vez da última modificação? Não faz sentido.

Para futuros Googlers, um erro editado que recebi:

PHP message: PHP Fatal error:  Uncaught Error: Class 'ComposerAutoloaderInitXXXXXXXXXXXXX' not found in /xxx/xxx/vendor/autoload.php:7
Stack trace:
#0 /xxx/xxx/bootstrap/app.php(3): require_once()
#1 /xxx/xxx/public/index.php(14): require('/xxx/xxx...')
#2 {main}
  thrown in /xxx/xxx/vendor/autoload.php on line 7" while reading response header from upstream: ...
---

O mesmo problema, nem todos os arquivos são sincronizados, --exact-timestamps não ajudou.

aws --version
aws-cli/1.18.22 Python/2.7.13 Linux/4.14.152-127.182.amzn2.x86_64 botocore/1.15.22

Eu não posso acreditar que este tíquete está aberto há tanto tempo ... mesmo problema aqui, onde está a obsessão do cliente da Amazon?

Não acredito que esse tíquete não foi fechado há algum tempo. Até onde eu posso dizer, ele funciona como projetado, mas os usuários (incluindo eu) fazem suposições sobre como ele deve funcionar e ficam surpresos quando ele não se comporta como eles esperavam.

• Quando um arquivo é sincronizado ou copiado _to_ s3, o carimbo de data / hora que ele recebe no intervalo é a data em que foi copiado, que é _sempre_ mais recente do que a data do arquivo de origem. É assim que o s3 funciona.
• Os arquivos são sincronizados apenas se o tamanho for alterado ou se o carimbo de data / hora no destino for _mais antigo_ do que a fonte.
• Isso significa que se os arquivos de origem forem atualizados, mas o tamanho dos arquivos permanecer inalterado e as datas desses arquivos alterados forem anteriores à data da última cópia, o s3 sync não os sincronizará novamente.
• Usar --exact-timestamps _only_ funciona ao copiar de s3 para local. Deliberadamente não é habilitado para local para s3 porque os carimbos de data / hora são _nunca_ iguais. Portanto, configurá-lo durante a sincronização de local para s3 não tem efeito.
• Eu não acho que o s3 calcula hashes para arquivos carregados, então não há como evitar o tamanho do arquivo e a data do último upload como verificações.

O ponto principal é que ele funciona conforme o planejado, mas existem vários casos de uso em que isso não é desejável. Conforme mencionado acima, resolvi isso usando s3 cp --recursive

@ jam13 obrigado pela explicação, agora tudo faz sentido em retrospectiva!

No entanto, eu diria que atualmente está mal documentado (eu teria esperado um grande aviso vermelho na documentação afirmando que --exact-timestamps só funciona _de s3 para local_ e também para s3 cli apenas resgatar em vez de silenciosamente ignorando o parâmetro) e um modo de comparação baseado em hash opcional é necessário para implementar um modo de sincronização de trabalho confiável.

Sim, a documentação não é boa e ignorar as opções silenciosamente é muito inútil. A ausência de qualquer gerenciamento ou mesmo comentários oficiais sobre este tíquete da AWS nos últimos 2 anos também fala por si.

@ jam13 Pesquisei em algumas documentações e descobri que preciso de --exact-timestamps para contornar alguns problemas do s3 para o local. Obrigado!

@kyleknap @KaibaLopez @stealthycoin alguma atualização sobre este?

Não acredito que esse tíquete não foi fechado há algum tempo. Até onde eu posso dizer, ele funciona como projetado, mas os usuários (incluindo eu) fazem suposições sobre como ele deve funcionar e ficam surpresos quando ele não se comporta como eles esperavam.

* When a file is synced or copied _to_ s3, the timestamp it receives on the bucket is the date it was copied, which is _always_ newer than the date of the source file. This is just how s3 works.

* Files are only synced if the size changes, or the timestamp on the target is _older_ than the source.

* This means that if source files are updated but the size of the files remains unchanged and the dates on those changed files pre-date when they were last copied, s3 sync will not sync them again.

* Using `--exact-timestamps` _only_ works when copying from s3 to local. It is deliberately not enabled for local to s3 because the timestamps are _never_ equal. So setting it when syncing from local to s3 has no effect.

* I don't think s3 calculates hashes for uploaded files, so there's no way of avoiding file size and last uploaded date as checks.

O ponto principal é que ele funciona conforme o planejado, mas existem vários casos de uso em que isso não é desejável. Conforme mencionado acima, resolvi isso usando s3 cp --recursive

O s3 faz o hash dos objetos, mas não de uma forma totalmente reconhecível se você não for o uploader , e armazena isso como a conhecida ETag . O problema é que a ETag depende do número de chunks e do tamanho do chunk usado quando o arquivo foi carregado. Se você não for o uploader, provavelmente não sabe o tamanho do bloco (mas pode obter o número de blocos da ETag). Não sei por que isso é feito dessa forma.

Isso provavelmente está funcionando como esperado, mas não como deveria. Deve ser trivial verificar se um arquivo foi alterado

É apenas um grande obstáculo para as pessoas ficarem inesperadamente fora de sincronia
dados. Existem 100 soluções alternativas diferentes que podem salvar a todos aqui
o tempo de leitura deste tíquete, junto com o tempo gasto descobrindo este
foi um problema em seu código-fonte. Por que eles não podem fazer um desses?

Na terça, 14 de abril de 2020 às 13:57 Keith Kelly [email protected]
escreveu:

Não acredito que esse tíquete não foi fechado há algum tempo. Tanto quanto eu posso
diga, funciona como projetado, mas os usuários (incluindo eu) fazem suposições sobre
como deveria funcionar e, em seguida, ficam surpresos quando não se comporta como eles
esperado.

• Quando um arquivo é sincronizado ou copiado _to_ s3, o carimbo de data / hora que ele recebe no intervalo é a data em que foi copiado, que é _sempre_ mais recente do que a data do arquivo de origem. É assim que o s3 funciona.

• Os arquivos são sincronizados apenas se o tamanho for alterado ou se o carimbo de data / hora no destino for _mais antigo_ do que a fonte.

• Isso significa que se os arquivos de origem forem atualizados, mas o tamanho dos arquivos permanecer inalterado e as datas desses arquivos alterados forem anteriores à data da última cópia, o s3 sync não os sincronizará novamente.

• Usar --exact-timestamps _only_ funciona ao copiar de s3 para local. Deliberadamente não é habilitado para local para s3 porque os carimbos de data / hora são _nunca_ iguais. Portanto, configurá-lo durante a sincronização de local para s3 não tem efeito.

• Eu não acho que o s3 calcula hashes para arquivos carregados, então não há como evitar o tamanho do arquivo e a data do último upload como verificações.

O ponto principal é que funciona conforme o esperado, mas existem vários casos de uso
onde isso não é desejável. Como acima mencionado
<# m_8540343689970969812_issuecomment-534061850> Eu trabalhei em torno disso
usando s3 cp --recursive

s3 faz o hash dos objetos, mas não de uma forma totalmente cognoscível
https://teppen.io/2018/10/23/aws_s3_verify_etags/ e armazena isso como
a conhecida ETag https://en.wikipedia.org/wiki/HTTP_ETag . O problema
é que a ETag depende do número de blocos e do tamanho do bloco que
o arquivo foi carregado. Se você não é o carregador, provavelmente não
saber o tamanho do bloco (mas pode obter o número de blocos da ETag). eu
não sei por que isso é feito dessa forma.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/aws/aws-cli/issues/3273#issuecomment-613677369 ou
Cancelar subscrição
https://github.com/notifications/unsubscribe-auth/ADUA4NKJMCUSGTNAAITGPXTRMTE2NANCNFSM4E3JNHPQ
.

>

...Tom

Tive o mesmo problema. Resolvido com a mudança da política de intervalo de origem para:

 "Action": [
                "s3:*"
            ],

Tive o problema com cp --recursive e sync .
Isso resolveu tudo. Tive duas ações que deveriam ter funcionado perfeitamente, mas não funcionaram. Experimente e diga-me se resolveu o seu problema.

Estou aqui para dizer que também estou tendo problemas com sync . A única razão que notei foi porque eu estava selando e verificando MHLs em ambas as extremidades. sync não funcionaria e faltavam cerca de 60 GB de 890 GB ao tentar acessar, pasta por pasta. Então eu encontrei este tópico e tentei cp --recursive e os dados começaram a fluir novamente. Verificarei o MHL uma última vez assim que obtiver o restante desses dados.

Escrevi um script para reproduzir o problema, uso:
aws-cli / 1.18.34 Python / 2.7.17 Darwin / 19.4.0 botocore / 1.13.50

Se você executar o script, verá que após o upload da alteração, a mesma alteração não é mais baixada. Este é o script:

#!/bin/bash
PROFILE=foobar #PUT YOUR PROFILE HERE
BUCKET=baz123  #PUT YOUR BUCKET HERE

mkdir -p test/local
mkdir -p test/s3

cat >test/s3/test.json <<EOF
{
  "__comment_logging": "set cookie expiration time of aws split, examples '+1 hour', '+5 days', '+100 days'",
  "splitCookieExpiration": "+3 hours"
}
EOF

#UPLOAD
aws --profile=$PROFILE s3 sync --delete test/s3 s3://$BUCKET/ 
#DOWNLOAD
aws --profile=$PROFILE s3 sync --delete s3://$BUCKET/ test/local


#CHANGE 
cat >test/s3/test.json <<EOF
{
  "__comment_logging": "set cookie expiration time of aws split, examples '+1 hour', '+5 days', '+100 days'",
  "splitCookieExpiration": "+2 hours"
}
EOF


#UPLOAD
aws --profile=$PROFILE s3 sync --delete test/s3 s3://$BUCKET/ 
#DOWNLOAD
aws --profile=$PROFILE s3 sync --delete s3://$BUCKET/ test/local

@htrappmann Leia @ jam13 a resposta https://github.com/aws/aws-cli/issues/3273#issuecomment -602514439 antes - não é um bug, é um recurso!

Obrigado pela dica @applerom , mas eu realmente não consigo entender como @ jam13 declara que "funciona como projetado". Uma ferramenta de sincronização deve ser projetada para manter a origem e o destino iguais, e isso não é fornecido com esta sincronização. O que o torna inútil para muitos aplicativos.

Além disso, se o tamanho do arquivo não for alterado, mas a data e hora da fonte for mais recente, nenhuma sincronização ocorrerá, como no meu script de exemplo.

Obrigado pela dica @applerom , mas eu realmente não consigo entender como @ jam13 declara que "funciona como projetado". Uma ferramenta de sincronização deve ser projetada para manter a origem e o destino iguais, e isso não é fornecido com esta sincronização. O que o torna inútil para muitos aplicativos.

Além disso, se o tamanho do arquivo não for alterado, mas a data e hora da fonte for mais recente, nenhuma sincronização ocorrerá, como no meu script de exemplo.

Parece que está fazendo a coisa errada, não é?

Fiz alguns outros testes para ver o que realmente precisava fazer para que o download ocorresse:

ls -l test/local/test.json
aws s3 sync --delete s3://$BUCKET/ test/local
touch -m -t 201901010000 test/local/test.json
ls -l test/local/test.json
aws s3 sync --delete s3://$BUCKET/ test/local
touch test/local/test.json
ls -l test/local/test.json
aws s3 sync --delete s3://$BUCKET/ test/local

Ao alterar a hora de modificação do arquivo para o ano passado, o s3 sync ainda não baixa o arquivo, portanto, não é simplesmente um problema de fuso horário.

Ao alterar a hora de modificação para agora (para que o arquivo local seja mais recente que o remoto), o s3 sync _faz_ download do arquivo!

Não consegui entender isso, então verifiquei os documentos, que estado (ao descrever a opção --exact-timestamps ):

O comportamento padrão é ignorar itens do mesmo tamanho, a menos que a versão local seja mais recente que a versão S3.

Usar --exact-timestamps para download funciona conforme o esperado (qualquer diferença nos carimbos de data / hora resulta em uma cópia), mas esse padrão parece estar invertido para mim.

Talvez em vez de dizer "funciona conforme projetado", eu deveria ter dito "funciona conforme documentado".

@ jam13 Uau, isso é tão estranho, e achei que é uma confusão na documentação!
Mas se esta é a nova maneira de corrigir bugs, basta colocá-los explicitamente na documentação ...

@ jam13

Não tenho certeza se podemos descartar o problema de fuso horário.
Todos os dias, quando faço a primeira alteração no console s3 e sincronizo aws s3 sync s3://$BUCKET . , ele sincroniza. Se eu fizer outra alteração no arquivo e sincronizá-lo, ele não será sincronizado.
Mas funciona no dia seguinte.

Isso me faz repensar se poderia ser por causa do fuso horário.

Portanto, verifiquei um pouco mais sobre o comando touch -m que você mencionou acima.

touch -m -t 201901010000 test/local/test.json
Ao alterar a hora de modificação do arquivo para o ano passado, o s3 sync ainda não baixa o arquivo, portanto, não é simplesmente um problema de fuso horário.

O comando touch acima retrata apenas o mtime. Ele não (e não pode) retroagir o ctime.
O S3 cli talvez use o ctime?

$ touch file
$ stat -x file
  File: "file"
  Size: 0            FileType: Regular File
  ...
  ...
Access: Mon Jul 20 21:59:11 2020
Modify: Mon Jul 20 21:59:11 2020
Change: Mon Jul 20 21:59:11 2020

$ touch -m -t 201901010000 file
$ stat -x file
  File: "file"
  Size: 0            FileType: Regular File
  ...
  ...
Access: Mon Jul 20 21:59:11 2020
Modify: Tue Jan  1 00:00:00 2019
Change: Mon Jul 20 22:01:48 2020

Acho que a sincronização de arquivos deve garantir que os arquivos sejam os mesmos localmente e remotamente. Não acho que estou sendo injusto ao dizer isso. Acho que aws s3 sync é mais um update que uma sincronização. Agora vou mudar cada implementação de aws s3 sync para aws s3 cp --recursive .

Obrigado @ jam13 pela explicação em https://github.com/aws/aws-cli/issues/3273#issuecomment -602514439