Aws-cli: La sincronización de AWS S3 no sincroniza todos los archivos

Posiblemente puede usar --exact-timestamps para solucionar esto, aunque eso puede resultar en cargas excesivas si está cargando.

Para ayudar en la reproducción, ¿podría darme información sobre uno de los archivos que no se sincroniza?

• ¿Cuál es el tamaño exacto del archivo localmente?
• ¿Cuál es el tamaño exacto del archivo en S3?
• ¿Cuál es la última hora modificada localmente?
• ¿Cuál es la última hora de modificación en S3?
• ¿Es el archivo local un enlace simbólico / detrás de un enlace simbólico?

Ejecución de comando de ejemplo
aws s3 sync s3: // depósito / / var / www / carpeta / --delete

Faltan varios archivos
Tamaño local exacto: 2625
Exacto s3: 2625
Sello de hora exacta local: 06-ene-2017 9:32:31
Sello de tiempo exacto s3: 20-Jun-2017 10:14:57
archivo normal en S3 y local

Hay varios casos así en una lista de alrededor de 50.000 archivos. Sin embargo, todos los que faltan sincronizados son varias veces el 20 de junio de 2017.

El uso de --exact-timestamps muestra muchos más archivos para descargar, aunque tienen exactamente el mismo contenido. Sin embargo, todavía faltan los del ejemplo anterior.

mismo problema aquí.
aws s3 sync dist/ s3://bucket --delete no cargó s3: //bucket/index.html con dist / index.html

dist / index.html y s3: //bucket/index.html tienen el mismo tamaño de archivo, pero su tiempo de modificación es diferente.

de hecho, algunas veces awscli subió el archivo, pero otras no

Lo mismo aquí, --exact-timestamps no ayuda - index.html no se sobrescribe.

Experimentamos que este problema estuvo bien hoy / la semana pasada. Nuevamente, index.html tiene el mismo tamaño de archivo, pero el contenido y los tiempos de modificación son diferentes.

¿Alguien está al tanto de una solución para esto?

Me acabo de encontrar con esto. El mismo problema que reportaron @icymind y @samdammers : el contenido de mi archivo (local) index.html había cambiado, pero su tamaño de archivo era el mismo que el de la copia anterior en S3. El comando {{aws s3 sync}} no lo cargó. Mi "solución" fue eliminar index.html de S3, y luego ejecutar la sincronización nuevamente (que luego lo cargó como si fuera un archivo nuevo, supongo).

Servidor: EC2 linux
Versión: aws-cli/1.16.108 Python/2.7.15 Linux/4.9.62-21.56.amzn1.x86_64 botocore/1.12.98

Después de aws s3 sync ejecutar más de 270T de datos, perdí algunos GB de archivos. Sync no copió archivos con caracteres especiales en absoluto.

Ejemplo de archivo /data/company/storage/projects/1013815/3.Company Estimates/B. Estimates

Tuve que usar cp -R -n

mismo problema aquí archivo xml del mismo tamaño pero diferente marca de tiempo no sincronizada correctamente

Pude reproducir este problema

bug.tar.gz
descargar el archivo tar adjunto y luego

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

verá que aunque repomd.xml en los directorios ayb difieren en contenido y marcas de tiempo
intentar sincronizar b no hace nada

Probado en
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

estoy viendo el mismo problema. tratando de sincronizar un directorio de archivos de s3 donde se actualizó un archivo a un directorio local. ese archivo no se actualiza en el directorio local

Yo también estoy viendo esto. En mi caso, es una aplicación de reacción con index.html que se refiere a archivos .js generados. Los estoy sincronizando con la opción --delete para eliminar archivos antiguos a los que ya no se hace referencia. El index.html a veces no se carga, lo que da como resultado un index.html antiguo que apunta a archivos .js que ya no existen.

¡Por lo tanto, mi sitio web deja de funcionar!

Actualmente no tengo ni idea de por qué está sucediendo esto.

¿Alguien tiene alguna idea o solución?

Tenemos el mismo problema, pero acabamos de encontrar una solución. Lo sé, no es la mejor manera, pero funciona:

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

Nos parece que la copia está funcionando bien, así que primero copiamos y luego usamos el comando de sincronización para eliminar archivos, que ya no están presentes.
Espero que el problema se solucione lo antes posible.

Agregué --exact-timestamps a mi canalización y el problema no se ha repetido. Pero fue intermitente en primer lugar, así que no puedo estar seguro de que lo haya solucionado. Si vuelve a suceder, iré con la sugerencia de @ marns93 .

Hemos resuelto este problema y --exact-timestamps resuelve nuestro problema. No estoy seguro de si es exactamente el mismo problema.

Estoy viendo este problema y es muy obvio porque cada llamada solo tiene que copiar un puñado (menos de una docena) de archivos.

La situación en la que sucede es como se informó anteriormente: si la carpeta en la que se está sync ed contiene un archivo con contenido de archivo diferente pero tamaño de archivo idéntico, sync omitirá copiar el nuevo archivo actualizado de S3.

Terminamos cambiando los scripts a aws s3 cp --recursive para solucionarlo, pero este es un error desagradable: durante mucho tiempo pensamos que teníamos algún tipo de condición de carrera en nuestra propia aplicación, sin darnos cuenta de que aws-cli era simplemente elegir no copiar los archivos actualizados.

También vi esto con un archivo html

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

Copié, pegué el comando s3 sync de una esencia de GitHub y tenía --size-only configurado. ¡Eliminar eso solucionó el problema!

Me encontré con este problema con los artefactos de compilación que se cargan en un depósito. Nuestro HTML tendía a cambiar solo los códigos hash para los enlaces de activos, por lo que el tamaño siempre era el mismo. La sincronización de S3 los omitía si la compilación era demasiado pronto después de una anterior. Ejemplo:

10:01 - Ejecuciones de la compilación 1
10:05 - Ejecuciones de construcción 2
10:06 - La compilación 1 se carga en s3
10:10 - La compilación 2 se carga en s3

La compilación 2 tiene archivos HTML con una marca de tiempo de 10:05, sin embargo, los archivos HTML cargados en s3 por la compilación 1 tienen una marca de tiempo de 10:06, ya que fue entonces cuando se crearon los objetos. Esto da como resultado que s3 sync los ignore, ya que los archivos remotos son "más nuevos" que los archivos locales.

Ahora estoy usando s3 cp --recursive seguido de s3 sync --delete como se sugirió anteriormente.

Espero que esto pueda ser útil para alguien.

Tuve el mismo problema a principios de esta semana; No estaba usando --size-only . Nuestro index.html era diferente por un solo carácter ( . fue a # ), por lo que el tamaño era el mismo, pero la marca de tiempo en s3 era 40 minutos antes que la marca de tiempo del nuevo índice .html. Eliminé el index.html como una solución temporal, pero no es factible volver a verificar cada implementación.

Lo mismo aquí, los archivos con el mismo nombre pero con diferente marca de tiempo y contenido no se sincronizan de S3 a local y --delete no ayuda

Experimentamos el mismo problema. No se copia un index.html con el mismo tamaño pero una marca de tiempo más reciente.

Este problema se informó hace más de un año. ¿Por qué no está arreglado?

En realidad, hace que el comando snyc sea inútil.

tiempo exacto

--exact-timestamps solucionó el problema

También me afecta este problema. Agregué --exact-timestamps y el problema pareció solucionar los archivos que estaba viendo. no he hecho una búsqueda exhaustiva. Tengo del orden de 100k archivos y 20gb, mucho menos que los otros aquí.

Me he enfrentado al mismo problema, aws s3 sync omitir algunos archivos, incluso con diferentes contenidos y diferentes fechas. El registro muestra que esos archivos omitidos están sincronizados, pero en realidad no.
Pero cuando ejecuto aws s3 sync nuevamente, esos archivos se sincronizaron. ¡Muy raro!

Tuve este problema cuando construí un sitio con Hugo y finalmente lo resolví. Utilizo submódulos para mi tema de Hugo y no los estaba tirando hacia abajo en CI. Esto estaba provocando avisos en Hugo pero no fallos.

# 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  

Una vez que actualicé los submódulos, todo funcionó como se esperaba.

También nos ha afectado este problema, tanto que una plataforma dejó de funcionar durante ~ 18 horas después de que un nuevo archivo vendor/autoload.php no se sincronizara y estuviera desactualizado con vendor/composer/autoload_real.php así que no se pudo cargar toda la aplicación.

Este es un problema _muy_ extraño, y no puedo creer que el problema haya estado abierto durante tanto tiempo.

¿Por qué una sincronización no usaría hash en lugar de la última modificación? Tiene 0 sentido.

Para los futuros empleados de Google, recibí un error redactado:

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

El mismo problema, no todos los archivos están sincronizados, --exact-timestamps no ayudó.

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

No puedo creer que este boleto esté abierto tanto tiempo ... el mismo problema aquí, ¿dónde está la obsesión del cliente de Amazon?

No puedo creer que este boleto no se haya cerrado hace algún tiempo. Por lo que puedo decir, funciona según lo diseñado, pero los usuarios (incluyéndome a mí) hacen suposiciones sobre cómo debería funcionar y luego se sorprenden cuando no se comporta como esperaban.

• Cuando un archivo se sincroniza o copia _to_ s3, la marca de tiempo que recibe en el depósito es la fecha en que se copió, que es _siempre_ más reciente que la fecha del archivo de origen. Así es como funciona s3.
• Los archivos solo se sincronizan si cambia el tamaño o si la marca de tiempo en el destino es _más antigua_ que la fuente.
• Esto significa que si los archivos de origen se actualizan pero el tamaño de los archivos permanece sin cambios y las fechas de esos archivos modificados son anteriores a la última vez que se copiaron, s3 sync no los volverá a sincronizar.
• El uso de --exact-timestamps _only_ funciona al copiar de s3 a local. No está habilitado deliberadamente para local en s3 porque las marcas de tiempo son _nunca_ iguales. Por lo tanto, configurarlo al sincronizar de local a s3 no tiene ningún efecto.
• No creo que s3 calcule hashes para los archivos cargados, por lo que no hay forma de evitar el tamaño del archivo y la fecha de la última carga como comprobaciones.

La conclusión es que funciona según lo previsto, pero hay varios casos de uso en los que esto no es deseable. Como se mencionó anteriormente, lo he solucionado usando s3 cp --recursive

@ jam13 gracias por la explicación, ¡ahora todo tiene sentido en retrospectiva!

Sin embargo, diría que actualmente está mal documentado (hubiera esperado una advertencia roja gruesa en la documentación que indicara que --exact-timestamps solo funciona _de s3 a local_ y también para que el cli de s3 simplemente salga en lugar de silenciosamente ignorando el parámetro) y un modo de comparación opcional basado en hash es necesario para implementar un modo de sincronización que funcione de manera confiable.

Sí, la documentación no es excelente e ignorar las opciones en silencio es muy inútil. La ausencia de comentarios de la administración o incluso oficiales sobre este ticket de AWS durante los últimos 2 años también dice mucho.

@ jam13 Investigué algunas documentaciones y descubrí que necesito --exact-timestamps para eludir algunos problemas de s3 a local. ¡Gracias!

@kyleknap @KaibaLopez @stealthycoin ¿ alguna actualización sobre este?

No puedo creer que este boleto no se haya cerrado hace algún tiempo. Por lo que puedo decir, funciona según lo diseñado, pero los usuarios (incluyéndome a mí) hacen suposiciones sobre cómo debería funcionar y luego se sorprenden cuando no se comporta como esperaban.

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

La conclusión es que funciona según lo previsto, pero hay varios casos de uso en los que esto no es deseable. Como se mencionó anteriormente, lo he solucionado usando s3 cp --recursive

s3 hace hash de los objetos, pero no de una manera totalmente conocida si usted no es el cargador , y lo almacena como el ETag familiar. El problema es que ETag depende de la cantidad de fragmentos y del tamaño de fragmentos utilizados cuando se cargó el archivo. Si no es el que subió el video, probablemente no sepa el tamaño del fragmento (pero puede obtener el número de fragmentos del ETag). No sé por qué se hace de esta manera.

Probablemente esté funcionando como se esperaba, pero no como debería. Debería ser trivial comprobar si un archivo ha cambiado

Es un gran problema para las personas experimentar inesperadamente la desincronización
datos. Hay 100 soluciones alternativas que podrían salvar a todos aquí
el tiempo de leer este boleto, junto con el tiempo dedicado a descubrir este
fue un problema en su código fuente. ¿Por qué no pueden hacer uno de estos?

El martes 14 de abril de 2020 a la 1:57 p.m. Keith Kelly [email protected]
escribió:

No puedo creer que este boleto no se haya cerrado hace algún tiempo. Tan lejos como pueda
decir, funciona según lo diseñado, pero los usuarios (incluyéndome a mí) hacen suposiciones sobre
cómo debería funcionar y luego se sorprenden cuando no se comporta como ellos
esperado.

• Cuando un archivo se sincroniza o copia _to_ s3, la marca de tiempo que recibe en el depósito es la fecha en que se copió, que es _siempre_ más reciente que la fecha del archivo de origen. Así es como funciona s3.

• Los archivos solo se sincronizan si cambia el tamaño o si la marca de tiempo en el destino es _más antigua_ que la fuente.

• Esto significa que si los archivos de origen se actualizan pero el tamaño de los archivos permanece sin cambios y las fechas de esos archivos modificados son anteriores a la última vez que se copiaron, s3 sync no los volverá a sincronizar.

• El uso de --exact-timestamps _only_ funciona al copiar de s3 a local. No está habilitado deliberadamente para local en s3 porque las marcas de tiempo son _nunca_ iguales. Por lo tanto, configurarlo al sincronizar de local a s3 no tiene ningún efecto.

• No creo que s3 calcule hashes para los archivos cargados, por lo que no hay forma de evitar el tamaño del archivo y la fecha de la última carga como comprobaciones.

La conclusión es que funciona según lo previsto, pero hay varios casos de uso
donde esto no es deseable. Como se ha mencionado más arriba
<# m_8540343689970969812_issuecomment-534061850> Lo solucioné
usando s3 cp --recursive

s3 hace hash de los objetos, pero no de una manera enteramente cognoscible
https://teppen.io/2018/10/23/aws_s3_verify_etags/ , y lo almacena como
el conocido ETag https://en.wikipedia.org/wiki/HTTP_ETag . El problema
es que la ETag depende del número de fragmentos y del tamaño del fragmento que
en el que se cargó el archivo. Si no eres el que lo subió, probablemente no
conocer el tamaño del fragmento (pero puede obtener el número de fragmentos de la ETag). I
no sé por qué se hace de esta manera.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/aws/aws-cli/issues/3273#issuecomment-613677369 , o
darse de baja
https://github.com/notifications/unsubscribe-auth/ADUA4NKJMCUSGTNAAITGPXTRMTE2NANCNFSM4E3JNHPQ
.

>

...Tomás

Tuve el mismo problema. Lo resolvió cambiando la política del depósito de origen a:

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

Tuve el problema con cp --recursive y sync .
Esto lo resolvió todo. Tuve dos acciones que deberían haber funcionado bien, pero no lo hicieron. Pruébelo y avíseme si resolvió su problema.

Entrando aquí para decir que también he tenido el problema con sync . La única razón por la que me di cuenta fue porque estaba sellando y verificando MHL en ambos extremos. sync no funcionaría, y me faltaban unos 60 GB de 890 GB, tratando de revisar, carpeta por carpeta. Luego encontré este hilo e intenté cp --recursive y los datos comenzaron a fluir nuevamente. Verificaré el MHL una última vez una vez que obtenga el resto de estos datos.

Escribí un script para reproducir el problema, utilizo:
aws-cli / 1.18.34 Python / 2.7.17 Darwin / 19.4.0 botocore / 1.13.50

Si ejecuta el script, verá que después de cargar el cambio, el mismo cambio ya no se descarga. Este es el guión:

#!/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 Lea la respuesta de @ jam13 https://github.com/aws/aws-cli/issues/3273#issuecomment -602514439 antes: ¡no es un error, es una característica!

Gracias por la pista @applerom , pero realmente no puedo entender cómo @ jam13 lo declara como "funciona según lo diseñado". Se debe diseñar una herramienta de sincronización para mantener el origen y el destino iguales, y esto simplemente no se da con esta sincronización. Lo que lo hace inútil para muchas aplicaciones.

Además, si el tamaño del archivo no ha cambiado pero la marca de tiempo de origen es más nueva, tampoco se realiza ninguna sincronización, como en mi script de ejemplo.

Gracias por la pista @applerom , pero realmente no puedo entender cómo @ jam13 lo declara como "funciona según lo diseñado". Se debe diseñar una herramienta de sincronización para mantener el origen y el destino iguales, y esto simplemente no se da con esta sincronización. Lo que lo hace inútil para muchas aplicaciones.

Además, si el tamaño del archivo no ha cambiado pero la marca de tiempo de origen es más nueva, tampoco se realiza ninguna sincronización, como en mi script de ejemplo.

Parece que está haciendo algo incorrecto, ¿no?

Ejecuté un par de otras pruebas para ver lo que realmente necesitaba hacer para que ocurriera la descarga:

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

Al cambiar la hora de modificación del archivo al año pasado, la sincronización s3 aún no descarga el archivo, por lo que no es simplemente un problema de zona horaria.

Al cambiar la hora de modificación a ahora (para que el archivo local sea más nuevo que el remoto), la sincronización s3 _descarga el archivo.

No pude encontrarle sentido a eso, así que verifiqué los documentos, que indican (al describir la opción --exact-timestamps ):

El comportamiento predeterminado es ignorar los elementos del mismo tamaño a menos que la versión local sea más reciente que la versión S3.

El uso de --exact-timestamps para la descarga funciona como se esperaba (cualquier diferencia en las marcas de tiempo da como resultado una copia), pero este valor predeterminado me parece al revés.

Quizás en lugar de decir "funciona según lo diseñado", debería haber dicho "funciona según lo documentado".

@ jam13 ¡ Vaya, eso es tan extraño, y pensé que era una confusión en la documentación!
Pero si esta es la nueva forma de corregir errores, simplemente póngalos explícitamente en la documentación ...

@ jam13

No estoy seguro de que podamos descartar el problema de la zona horaria.
Todos los días, cuando hago el primer cambio en la consola s3 y sincronizo aws s3 sync s3://$BUCKET . , se sincroniza. Si realizo otro cambio en el archivo y luego lo sincronizo, no se sincroniza.
Pero funciona al día siguiente.

Esto me hace replantearme si podría deberse a la zona horaria.

Así que verifique un poco más sobre el comando touch -m que mencionó anteriormente.

touch -m -t 201901010000 test/local/test.json
Al cambiar la hora de modificación del archivo al año pasado, la sincronización s3 aún no descarga el archivo, por lo que no es simplemente un problema de zona horaria.

El comando táctil anterior solo retrocede el mtime. No tiene (y no puede) una fecha anterior al ctime.
¿El cli S3 quizás usa el 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

Creo que las sincronizaciones de archivos deberían garantizar que los archivos de forma local y remota sean los mismos. No creo que esté siendo injusto al decir eso. Creo que aws s3 sync es más un update que una sincronización. Ahora voy a cambiar cada implementación de aws s3 sync a aws s3 cp --recursive .

Gracias @ jam13 por la explicación en https://github.com/aws/aws-cli/issues/3273#issuecomment -602514439