s3cmd
v2.4.0
Listas de correo de S3tools/S3cmd:
S3cmd requiere Python 2.6 o posterior. Python 3+ también es compatible a partir de la versión 2 de S3cmd.
Ver instrucciones de instalación.
S3cmd ( s3cmd ) es una herramienta de línea de comandos y un cliente gratuitos para cargar, recuperar y administrar datos en Amazon S3 y otros proveedores de servicios de almacenamiento en la nube que utilizan el protocolo S3, como Google Cloud Storage o DreamHost DreamObjects. Es más adecuado para usuarios avanzados que están familiarizados con los programas de línea de comandos. También es ideal para secuencias de comandos por lotes y copias de seguridad automatizadas en S3, activadas desde cron, etc.
S3cmd está escrito en Python. Es un proyecto de código abierto disponible bajo la licencia pública GNU v2 (GPLv2) y es gratuito tanto para uso comercial como privado. Sólo tendrás que pagarle a Amazon por usar su almacenamiento.
Se han agregado muchas características y opciones a S3cmd, desde su primer lanzamiento en 2008.... recientemente contamos más de 60 opciones de línea de comando, incluidas cargas de varias partes, cifrado, copia de seguridad incremental, sincronización de s3, ACL y administración de metadatos, S3. ¡Tamaño del depósito, políticas del depósito y más!
Amazon S3 proporciona un servicio de almacenamiento administrado accesible desde Internet donde cualquiera puede almacenar cualquier cantidad de datos y recuperarlos más tarde.
S3 es un servicio pago operado por Amazon. Antes de almacenar algo en S3, debe registrarse para obtener una cuenta "AWS" (donde AWS = Amazon Web Services) para obtener un par de identificadores: clave de acceso y clave secreta. Deberá proporcionar estas claves a S3cmd. Piense en ellos como si fueran un nombre de usuario y una contraseña para su cuenta S3.
Al momento de escribir este artículo, los costos de usar S3 son (en USD):
$0,023 por GB por mes de espacio de almacenamiento utilizado
más
$0.00 por GB - todos los datos cargados
más
$0,000 por GB: primer 1 GB/mes de datos descargados $0,090 por GB: hasta 10 TB/mes de datos descargados $0,085 por GB: siguientes 40 TB/mes de datos descargados $0,070 por GB: próximos 100 TB/mes de datos descargados $0,050 por GB: datos descargados / mes más de 150 TB
más
$0,005 por cada 1000 solicitudes PUT, COPY o LIST $0,004 por cada 10,000 GET y todas las demás solicitudes
Si, por ejemplo, el 1 de enero subes 2 GB de fotos en JPEG de tus vacaciones en Nueva Zelanda, a finales de enero se te cobrará $0,05 por usar 2 GB de espacio de almacenamiento durante un mes, $0,0 por cargar 2 GB de datos y un unos centavos para las solicitudes. Eso equivale a poco más de $0,06 por una copia de seguridad completa de sus preciadas fotografías de vacaciones.
En febrero no lo tocas. Tus datos todavía están en los servidores S3, por lo que pagas $0,06 por esos dos gigabytes, pero no se te cobrará ni un solo centavo por ninguna transferencia. Eso equivale a $0,05 como costo continuo de su copia de seguridad. No está tan mal.
En marzo, permites el acceso de lectura anónimo a algunas de tus imágenes y tus amigos descargan, digamos, 1500 MB de ellas. Como los archivos son de su propiedad, usted es responsable de los costos incurridos. Eso significa que a finales de marzo se te cobrarán $0,05 por el almacenamiento más $0,045 por el tráfico de descarga generado por tus amigos.
No hay contrato mínimo mensual ni tarifa de instalación. Lo que usas es lo que pagas. Al principio mi factura solía ser de 0,03 dólares estadounidenses o incluso de cero.
Ese es, en pocas palabras, el modelo de precios de Amazon S3. Consulte la página de inicio de Amazon S3 para obtener más detalles.
No hace falta decir que todo este dinero lo cobra el propio Amazon, obviamente no hay ningún pago por usar S3cmd :-)
Los archivos almacenados en S3 se denominan "objetos" y sus nombres se denominan oficialmente "claves". Dado que esto a veces resulta confuso para los usuarios, solemos referirnos a los objetos como "archivos" o "archivos remotos". Cada objeto pertenece exactamente a un "cubo".
Para describir objetos en el almacenamiento de S3, inventamos un esquema similar a URI de la siguiente forma:
s3://BUCKET
o
s3://BUCKET/OBJECT
Los depósitos son algo así como directorios o carpetas con algunas restricciones:
Es una buena idea utilizar nombres de depósitos compatibles con DNS. Eso, por ejemplo, significa que no debes utilizar caracteres en mayúsculas. Si bien el cumplimiento de DNS no es estrictamente necesario, algunas funciones que se describen a continuación no están disponibles para depósitos con nombres incompatibles con DNS. Un paso más es utilizar un nombre de dominio completo (FQDN) para un depósito, lo que tiene aún más beneficios.
Busque "Hosts virtuales" más adelante en este texto para obtener más detalles sobre los depósitos con nombre FQDN.
A diferencia de los depósitos, casi no hay restricciones en los nombres de los objetos. Puede ser cualquier cadena UTF-8 de hasta 1024 bytes de longitud. Curiosamente, el nombre del objeto puede contener una barra diagonal (/), por lo que my/funny/picture.jpg es un nombre de objeto válido. Tenga en cuenta que no hay directorios ni depósitos llamados my y funny ; en realidad es un nombre de objeto único llamado my/funny/picture.jpg y a S3 no le importa en absoluto que parezca una estructura de directorio.
El URI completo de dicha imagen podría ser, por ejemplo:
s3://my-bucket/my/funny/picture.jpg
Los archivos almacenados en S3 pueden ser privados o públicos. Los Privados sólo son legibles por el usuario que los subió, mientras que los Públicos pueden ser leídos por cualquiera. Además, se puede acceder a los archivos públicos mediante el protocolo HTTP, no sólo mediante s3cmd o una herramienta similar.
La ACL (Lista de control de acceso) de un archivo se puede configurar en el momento de la carga usando las opciones --acl-public o --acl-private con los comandos s3cmd put o s3cmd sync (ver más abajo).
Alternativamente, la ACL se puede modificar para archivos remotos existentes con el comando s3cmd setacl --acl-public (o --acl-private ).
Vaya a https://aws.amazon.com/s3, haga clic en el botón "Registrarse en el servicio web" en la columna de la derecha y realice el registro. Deberá proporcionar los datos de su tarjeta de crédito para permitir que Amazon le cobre por el uso de S3. Al final deberías tener tus claves de acceso y secretas.
Si configura un usuario de IAM independiente, la clave de acceso de ese usuario debe tener al menos los siguientes permisos para hacer cualquier cosa:
Se pueden encontrar otras políticas de ejemplo en https://docs.aws.amazon.com/AmazonS3/latest/dev/example-policies-s3.html
s3cmd --configureSe le pedirán las dos claves: cópielas y péguelas desde su correo electrónico de confirmación o desde la página de su cuenta de Amazon. ¡Cuidado al copiarlos! Distinguen entre mayúsculas y minúsculas y deben ingresarse con precisión o seguirá recibiendo errores sobre firmas no válidas o similares.
Recuerde agregar permisos s3:ListAllMyBuckets a las claves o obtendrá un error AccessDenied mientras prueba el acceso.
s3cmd ls para enumerar todos sus depósitos.Como acaba de comenzar a usar S3, no hay depósitos de su propiedad a partir de ahora. Entonces la salida estará vacía.
s3cmd mb s3://my-new-bucket-name Como se mencionó anteriormente, los nombres de los depósitos deben ser únicos entre todos los usuarios de S3. Eso significa que los nombres simples como "prueba" o "asdf" ya están en uso y debes inventar algo más original. Para demostrar tantas funciones como sea posible, creemos un depósito con nombre FQDN s3://public.s3tools.org :
$ s3cmd mb s3://public.s3tools.org
Bucket 's3://public.s3tools.org' created
s3cmd lsAhora deberías ver tu depósito recién creado:
$ s3cmd ls
2009-01-28 12:34 s3://public.s3tools.org
$ s3cmd ls s3://public.s3tools.org
$
Está vacío, de hecho.
$ s3cmd put some-file.xml s3://public.s3tools.org/somefile.xml
some-file.xml -> s3://public.s3tools.org/somefile.xml [1 of 1]
123456 of 123456 100% in 2s 51.75 kB/s done
Cargue un árbol de dos directorios en el 'directorio' virtual del depósito:
$ s3cmd put --recursive dir1 dir2 s3://public.s3tools.org/somewhere/
File 'dir1/file1-1.txt' stored as 's3://public.s3tools.org/somewhere/dir1/file1-1.txt' [1 of 5]
File 'dir1/file1-2.txt' stored as 's3://public.s3tools.org/somewhere/dir1/file1-2.txt' [2 of 5]
File 'dir1/file1-3.log' stored as 's3://public.s3tools.org/somewhere/dir1/file1-3.log' [3 of 5]
File 'dir2/file2-1.bin' stored as 's3://public.s3tools.org/somewhere/dir2/file2-1.bin' [4 of 5]
File 'dir2/file2-2.txt' stored as 's3://public.s3tools.org/somewhere/dir2/file2-2.txt' [5 of 5]
Como puede ver, no tuvimos que crear el 'directorio' /somewhere . De hecho, es sólo un prefijo de nombre de archivo, no un directorio real y no es necesario crearlo de ninguna manera de antemano.
En lugar de usar put con la opción --recursive , también puedes usar el comando sync :
$ s3cmd sync dir1 dir2 s3://public.s3tools.org/somewhere/
$ s3cmd ls s3://public.s3tools.org
DIR s3://public.s3tools.org/somewhere/
2009-02-10 05:10 123456 s3://public.s3tools.org/somefile.xml
Utilice --recursive (o -r) para enumerar todos los archivos remotos:
$ s3cmd ls --recursive s3://public.s3tools.org
2009-02-10 05:10 123456 s3://public.s3tools.org/somefile.xml
2009-02-10 05:13 18 s3://public.s3tools.org/somewhere/dir1/file1-1.txt
2009-02-10 05:13 8 s3://public.s3tools.org/somewhere/dir1/file1-2.txt
2009-02-10 05:13 16 s3://public.s3tools.org/somewhere/dir1/file1-3.log
2009-02-10 05:13 11 s3://public.s3tools.org/somewhere/dir2/file2-1.bin
2009-02-10 05:13 8 s3://public.s3tools.org/somewhere/dir2/file2-2.txt
$ s3cmd get s3://public.s3tools.org/somefile.xml some-file-2.xml
s3://public.s3tools.org/somefile.xml -> some-file-2.xml [1 of 1]
123456 of 123456 100% in 3s 35.75 kB/s done
$ md5sum some-file.xml some-file-2.xml
39bcb6992e461b269b95b3bda303addf some-file.xml
39bcb6992e461b269b95b3bda303addf some-file-2.xml
Las sumas de comprobación del archivo original coinciden con las de los recuperados. Parece que funcionó :-)
Para recuperar un 'árbol de directorios' completo de S3 utilice get recursivo:
$ s3cmd get --recursive s3://public.s3tools.org/somewhere
File s3://public.s3tools.org/somewhere/dir1/file1-1.txt saved as './somewhere/dir1/file1-1.txt'
File s3://public.s3tools.org/somewhere/dir1/file1-2.txt saved as './somewhere/dir1/file1-2.txt'
File s3://public.s3tools.org/somewhere/dir1/file1-3.log saved as './somewhere/dir1/file1-3.log'
File s3://public.s3tools.org/somewhere/dir2/file2-1.bin saved as './somewhere/dir2/file2-1.bin'
File s3://public.s3tools.org/somewhere/dir2/file2-2.txt saved as './somewhere/dir2/file2-2.txt'
Como no se especificó el directorio de destino, s3cmd guardó la estructura del directorio en un directorio de trabajo actual ('.').
Hay una diferencia importante entre:
get s3://public.s3tools.org/somewhere
y
get s3://public.s3tools.org/somewhere/
(tenga en cuenta la barra diagonal final)
s3cmd siempre usa la última parte de la ruta, es decir, la palabra después de la última barra, para nombrar archivos.
En el caso de s3://.../somewhere la última parte de la ruta es 'en algún lugar' y, por lo tanto, la obtención recursiva nombra los archivos locales como algún lugar/dir1, algún lugar/dir2, etc.
Por otro lado, en s3://.../somewhere/ la última parte de la ruta está vacía y s3cmd solo creará 'dir1' y 'dir2' sin el prefijo 'somewhere/':
$ s3cmd get --recursive s3://public.s3tools.org/somewhere/ ~/
File s3://public.s3tools.org/somewhere/dir1/file1-1.txt saved as '~/dir1/file1-1.txt'
File s3://public.s3tools.org/somewhere/dir1/file1-2.txt saved as '~/dir1/file1-2.txt'
File s3://public.s3tools.org/somewhere/dir1/file1-3.log saved as '~/dir1/file1-3.log'
File s3://public.s3tools.org/somewhere/dir2/file2-1.bin saved as '~/dir2/file2-1.bin'
¿Ver? Es ~/dir1 y no ~/somewhere/dir1 como estaba en el ejemplo anterior.
Elimine todo lo que se encuentra en s3://public.s3tools.org/somewhere/
$ s3cmd del --recursive s3://public.s3tools.org/somewhere/
File s3://public.s3tools.org/somewhere/dir1/file1-1.txt deleted
File s3://public.s3tools.org/somewhere/dir1/file1-2.txt deleted
...
Ahora intenta quitar el cubo:
$ s3cmd rb s3://public.s3tools.org
ERROR: S3 error: 409 (BucketNotEmpty): The bucket you tried to delete is not empty
Ay, nos olvidamos de s3://public.s3tools.org/somefile.xml . Podemos forzar la eliminación del depósito de todos modos:
$ s3cmd rb --force s3://public.s3tools.org/
WARNING: Bucket is not empty. Removing all the objects from it first. This may take some time...
File s3://public.s3tools.org/somefile.xml deleted
Bucket 's3://public.s3tools.org/' removed
El uso básico es tan simple como se describe en la sección anterior.
Puede aumentar el nivel de detalle con la opción -v y, si realmente desea saber qué hace el programa bajo su capó, ejecútelo con -d para ver todos los resultados de 'depuración'.
Después de configurarlo con --configure todas las opciones disponibles se incluyen en su archivo ~/.s3cfg . Es un archivo de texto listo para ser modificado en tu editor de texto favorito.
Los comandos de transferencia (put, get, cp, mv y sync) continúan transfiriéndose incluso si falla un objeto. Si ocurre una falla, la falla se envía a stderr y el estado de salida será EX_PARTIAL (2). Si se especifica la opción --stop-on-error , o la opción de configuración stop_on_error es verdadera, las transferencias se detienen y se devuelve un código de error apropiado.
Para obtener más información, consulte la página de inicio de S3cmd/S3tools.
Copyright (C) 2007-2023 TGRMN Software (https://www.tgrmn.com), Sodria SAS (https://www.sodria.com/) y colaboradores
Este programa es software gratuito; puede redistribuirlo y/o modificarlo según los términos de la Licencia Pública General GNU publicada por la Free Software Foundation; ya sea la versión 2 de la Licencia o (a su elección) cualquier versión posterior.
Este programa se distribuye con la esperanza de que sea de utilidad, pero SIN NINGUNA GARANTÍA; sin siquiera la garantía implícita de COMERCIABILIDAD o IDONEIDAD PARA UN PROPÓSITO PARTICULAR. Consulte la Licencia pública general de GNU para obtener más detalles.
