Subidas eficientes de archivos por CLI con código abierto

Tim Koschützki

Cofundador · Berlín, Alemania · Mostrar bio

Subir archivos desde una interfaz de línea de comandos (CLI) mantiene las manos en el teclado y encaja a la perfección en scripts de automatización, pipelines de CI/CD y la administración de servidores sin interfaz gráfica. Este artículo repasa algunas herramientas populares de código abierto, muestra cómo configurarlas y comparte consejos prácticos de fiabilidad y seguridad para cuando necesites gestionar subidas en la CLI.

¿Por qué subir archivos desde la CLI?

Gestionar las subidas de archivos desde la línea de comandos tiene varias ventajas:

• Automatización: Integra las transferencias de archivos sin fricciones en tus pipelines de compilación o despliegue.
• Programación: Programa fácilmente tareas como copias de seguridad en horas de baja demanda con cron o temporizadores de systemd.
• Scripting: Combina herramientas de CLI dentro de scripts de shell para flujos de trabajo complejos y reproducibles.
• Acceso remoto: Evita la fricción de las interfaces gráficas cuando trabajas por SSH en servidores remotos.

Compara herramientas populares de subida por CLI

Varias herramientas excelentes de código abierto cubren distintas necesidades de subida de archivos por CLI:

El resto de esta guía se centra en dos opciones habituales: s3cmd para subidas robustas a almacenamiento de objetos en la nube y transfer.sh para compartir archivos de forma rápida y puntual. Los principios se aplican de forma general.

Usa s3cmd para subidas a almacenamiento en la nube

s3cmd es una utilidad de Python madura y muy completa, diseñada para interactuar con Amazon S3 y con servicios de almacenamiento de objetos compatibles con S3 como MinIO, Wasabi, Backblaze B2 y otros.

Instala s3cmd

Usa un entorno de ejecución de Python 3 con mantenimiento. Con pipx⁠ instalado, mantén s3cmd aislado de los paquetes de Python de tu sistema:

pipx install s3cmd

# Or use system package managers (May lag behind the latest version)
# Debian / Ubuntu
sudo apt-get update && sudo apt-get install s3cmd

# macOS via homebrew
brew install s3cmd

Verifica la instalación: s3cmd --version debería mostrar 2.4.0 o una versión más reciente.

Configura las credenciales

Ejecuta el asistente de configuración interactivo:

s3cmd --configure

Se te pedirán tu Access Key ID, tu Secret Access Key, la región predeterminada y tus preferencias de cifrado y HTTPS. Los ajustes se guardan en un archivo .s3cfg en tu directorio personal. En entornos automatizados, considera usar variables de entorno (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY y AWS_SESSION_TOKEN para credenciales temporales) o roles de IAM en lugar de guardar las claves en el archivo de configuración. Define la región del bucket con --region o bucket_location en .s3cfg; AWS_DEFAULT_REGION no configura s3cmd.

Ejemplos de subida

# Define your target bucket (replace with your actual bucket name)
aws_bucket="s3://your-unique-bucket-name"

# Upload a single file to a specific path within the bucket
s3cmd put report.pdf "$aws_bucket/reports/"

# Synchronize a local directory with a path in the bucket (additive: nothing is deleted)
s3cmd sync ./local-data/ "$aws_bucket/data-backup/"

# Only if you really want the remote to mirror the local side, including deletions.
# --delete-removed deletes every remote object with no local counterpart, so a typo
# in the source path wipes the prefix. Always confirm with --dry-run first.
s3cmd sync --delete-removed --dry-run ./local-data/ "$aws_bucket/data-backup/"

# Upload a file with S3 server-side encryption (SSE-S3)
# Note: --encrypt is *client-side* GPG encryption, which is a different thing
s3cmd put --server-side-encryption sensitive-data.zip "$aws_bucket/private/"

Ajusta los parámetros para archivos grandes

Para subidas de archivos grandes, s3cmd admite subidas multiparte, que dividen el archivo en fragmentos más pequeños.

# Upload a large file in 50 MiB chunks, with up to 5 retries and a progress bar
s3cmd put \
  --multipart-chunk-size-mb=50 \
  --max-retries=5 \
  --progress \
  large-video.mp4 "$aws_bucket/videos/"

Usa transfer.sh para compartir archivos rápidamente

transfer.sh ofrece una forma sencilla de compartir archivos rápidamente desde la línea de comandos. Aunque han existido instancias públicas, ahora el proyecto recomienda sobre todo alojarlo por tu cuenta para mayor fiabilidad.

Ejecuta tu propia instancia de transfer.sh

Puedes ejecutar transfer.sh fácilmente con Docker. El siguiente comando inicia una instancia temporal que guarda los archivos en /tmp dentro del contenedor:

# Start a disposable server on host port 8080
# Files will be stored in /tmp inside the container
docker run -d --rm -p 127.0.0.1:8080:8080 \
  --name transfersh \
  dutchcoders/transfer.sh:latest \
  --provider local --basedir /tmp/

Este ejemplo desechable es anónimo y solo escucha en la interfaz de loopback. Usa archivos de prueba sin información sensible; configura la autenticación y HTTPS antes de exponer una instancia a otros usuarios. Para un almacenamiento persistente, monta un directorio del host en /tmp dentro del contenedor (por ejemplo, -v /path/on/host:/tmp). Consulta la documentación de transfer.sh para conocer configuraciones más avanzadas.

Comparte un archivo con tu instancia

Cuando tu instancia esté en marcha (reemplaza localhost:8080 si es necesario):

# Upload diagram.png to your self-hosted transfer.sh
# The command outputs the shareable URL upon successful upload
curl --fail --show-error --upload-file ./diagram.png http://localhost:8080/diagram.png

Alternativas públicas prácticas

Si alojarlo por tu cuenta no resulta práctico para compartir algo rápido y puntual, varios servicios públicos ofrecen una funcionalidad similar:

# Upload to file.io (file expires after first download)
# -F builds a multipart/form-data body; -f makes curl fail on HTTP errors
curl -fsS -F "file=@backup.tar.gz" https://file.io

# Upload using temp.sh's documented multipart endpoint
curl -fsS -F "file=@notes.txt" https://temp.sh/upload

Consulta los límites de retención y los términos vigentes en file.io⁠ y temp.sh⁠ antes de usarlos. No envíes archivos confidenciales a un servicio público anónimo; una URL de descarga imposible de adivinar no es un control de acceso.

Protege tus subidas por CLI

Cuando automatizas transferencias de archivos, la seguridad es fundamental:

1. Usa HTTPS: Prefiere siempre endpoints HTTPS (s3cmd usa HTTPS de forma predeterminada) para proteger las credenciales y los datos en tránsito. Evita el HTTP sin cifrar.
2. Cifra los datos sensibles: Para el cifrado del lado del servidor, usa s3cmd --server-side-encryption (SSE-S3) o --server-side-encryption-kms-id KEY_ID (SSE-KMS); el proveedor cifra el objeto después de que llega. s3cmd --encrypt hace lo contrario: es cifrado GPG del lado del cliente, y falla a menos que gpg_command y gpg_passphrase estén definidos en .s3cfg. Herramientas independientes como age o gpg cubren ese mismo terreno del lado del cliente.
3. Gestiona las credenciales de forma segura: Evita escribir claves de acceso o secretos directamente en los scripts. Usa variables de entorno, herramientas dedicadas de gestión de secretos (como HashiCorp Vault) o roles de IAM (para entornos en la nube como AWS EC2) que otorguen credenciales temporales con privilegios mínimos. Mantén los archivos .s3cfg fuera del control de versiones.
4. Aplica el mínimo privilegio: Configura políticas de IAM o políticas de bucket para otorgar solo los permisos necesarios (por ejemplo, s3:PutObject para las subidas, pero no s3:DeleteObject si no se requiere eliminar). Restringe el acceso público salvo que sea absolutamente necesario. Considera políticas de bucket que exijan cifrado al subir.
5. Limita la tasa de transferencia: Si haces subidas masivas, usa opciones de limitación (s3cmd --limit-rate=1M para 1 MiB/s, rclone --bwlimit 1M) para no saturar los enlaces de red ni alcanzar los límites de tasa de la API. Implementa un retroceso exponencial en tus scripts cuando encuentres errores de limitación de tasa (como HTTP 429).

Automatiza con temporizadores de systemd

En los sistemas Linux modernos, los temporizadores de systemd ofrecen una alternativa robusta a cron para programar tareas. Gestionan las ejecuciones perdidas (por ejemplo, si el servidor estuvo caído) y ofrecen una mejor integración con el registro de logs.

Así puedes configurar la subida diaria de una copia de seguridad con s3cmd:

1. Crea el archivo de unidad de servicio /etc/systemd/system/backup-upload.service:

[Unit]
Description=Tar and upload nightly backup to S3
# Ensures network is up before starting
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
# Path to your backup script
ExecStart=/opt/scripts/backup-upload.sh
# Run the script as a specific user (create this user if needed)
User=backup
Group=backup
# Set environment variables for s3cmd if not using .s3cfg or IAM roles.
# These names are case-sensitive: lowercase variants are ignored.
# Environment="AWS_ACCESS_KEY_ID=your_key_id"
# Environment="AWS_SECRET_ACCESS_KEY=your_secret_key"
# Configure bucket_location in the backup user's .s3cfg for the bucket's region.

[Install]
WantedBy=multi-user.target

2. Crea el archivo de unidad del temporizador /etc/systemd/system/backup-upload.timer:

[Unit]
Description=Run backup-upload.service daily at 2 AM

[Timer]
# Run daily at 2:00 am
OnCalendar=*-*-* 02:00:00
# Run on boot if the last scheduled run was missed
Persistent=true
Unit=backup-upload.service

[Install]
WantedBy=timers.target

3. Crea el script de copia de seguridad /opt/scripts/backup-upload.sh (asegúrate de que sea ejecutable: chmod +x /opt/scripts/backup-upload.sh y de que pertenezca al usuario backup: chown backup:backup /opt/scripts/backup-upload.sh):

#!/usr/bin/env bash
# Exit immediately if a command exits with a non-zero status.
# Treat unset variables as an error.
# Pipelines fail if any command fails, not just the last one.
set -euo pipefail

# Configuration
S3_BUCKET="s3://your-unique-bucket-name/backups" # Replace with your bucket path
BACKUP_SOURCE_DIR="/var/www/my-app-data"         # Replace with the directory to back up
TIMESTAMP=$(date +%Y-%m-%d_%H-%M-%S)
# A private random directory prevents collisions and predictable /tmp symlink writes.
ARCHIVE_DIR=$(mktemp -d "${TMPDIR:-/tmp}/backup.XXXXXX")
ARCHIVE_FILE="$ARCHIVE_DIR/backup-${TIMESTAMP}.tar.gz"
trap 'rm -rf -- "$ARCHIVE_DIR"' EXIT
LOG_FILE="/var/log/backup-upload.log" # Ensure 'backup' user can write here

# Redirect stdout and stderr to the log file
exec >>"$LOG_FILE" 2>&1

echo "----------------------------------------"
echo "[$(date)] Starting backup process..."

# Create the compressed archive
echo "[$(date)] Creating archive: $ARCHIVE_FILE from $BACKUP_SOURCE_DIR"
# Use -C to change directory, avoiding leading paths in the archive
tar -czf "$ARCHIVE_FILE" -C "$(dirname "$BACKUP_SOURCE_DIR")" "$(basename "$BACKUP_SOURCE_DIR")"
echo "[$(date)] Archive created successfully."

# Upload to S3 using s3cmd
echo "[$(date)] Uploading $ARCHIVE_FILE to $S3_BUCKET"
# A backslash only continues a line when it is the *last* character on it,
# so keep comments on their own lines above the flags they describe.
# --storage-class: Infrequent Access, for cost savings
# --acl-private:   keep the object private
# --progress:      record transfer progress in the log
s3cmd put \
  --storage-class=STANDARD_IA \
  --acl-private \
  --progress \
  "$ARCHIVE_FILE" "$S3_BUCKET/"
echo "[$(date)] Upload completed."

echo "[$(date)] Backup process finished successfully."
echo "----------------------------------------"

exit 0

4. Habilita e inicia el temporizador:

# Reload systemd so it picks up the new unit files
sudo systemctl daemon-reload
# Enable the timer to start on boot
sudo systemctl enable backup-upload.timer
# Start the timer now (it fires according to OnCalendar)
sudo systemctl start backup-upload.timer
# Check the status
sudo systemctl status backup-upload.timer
sudo systemctl status backup-upload.service
# List active timers
sudo systemctl list-timers --all

Recuerda configurar la rotación de logs (por ejemplo, con logrotate) para /var/log/backup-upload.log.

Soluciona problemas comunes

Incorpora Transloadit para subidas web y móviles

Aunque las herramientas de CLI destacan en contextos de servidor y de automatización, manejar las subidas directamente desde navegadores web o aplicaciones móviles requiere otras soluciones que gestionen las interrupciones de red, informen del progreso y permitan la reanudación.

Aquí es donde entra en juego el Robot /upload/handle de Transloadit. Está diseñado específicamente para subidas robustas del lado del cliente.

{
  "steps": {
    ":original": {
      "robot": "/upload/handle",
      "result": true
    }
  }
}

Puedes integrar este Robot con bibliotecas de front-end como Uppy (nuestro versátil cargador de archivos) o con cualquier cliente compatible con el protocolo tus de subidas reanudables⁠. Esta combinación aporta funciones como pausar y reanudar subidas, reintentos automáticos y actualizaciones de progreso en tiempo real, que mejoran la experiencia de usuario en las aplicaciones de cara al cliente.

¡Feliz subida de archivos!