Effiziente Datei-Uploads per CLI mit Open-Source-Tools

Tim Koschützki

Mitgründer · Berlin, Deutschland · Bio anzeigen

Dateien über eine Kommandozeilenschnittstelle (CLI) hochzuladen, hält die Hände auf der Tastatur und fügt sich nahtlos in Automatisierungsskripte, CI/CD-Pipelines und die Verwaltung von Headless-Servern ein. Dieser Beitrag stellt einige beliebte Open-Source-Tools vor, zeigt deren Einrichtung und gibt praktische Tipps zu Zuverlässigkeit und Sicherheit, wenn Sie Uploads auf der CLI abwickeln müssen.

Warum von der CLI aus hochladen?

Datei-Uploads über die Kommandozeile abzuwickeln, bietet mehrere Vorteile:

• Automatisierung: Dateiübertragungen nahtlos in Build- oder Deployment-Pipelines integrieren.
• Zeitplanung: Aufgaben wie Backups außerhalb der Stoßzeiten einfach mit Timern von cron oder systemd planen.
• Skripting: CLI-Tools in Shell-Skripten für komplexe, reproduzierbare Workflows kombinieren.
• Fernzugriff: GUI-Reibung vermeiden, wenn Sie per SSH auf entfernten Servern arbeiten.

Beliebte CLI-Upload-Tools im Vergleich

Mehrere hervorragende Open-Source-Tools decken unterschiedliche Anforderungen an Datei-Uploads über die CLI ab:

Der Rest dieses Leitfadens konzentriert sich auf zwei verbreitete Optionen: s3cmd für robuste Uploads in Cloud-Object-Storage und transfer.sh für schnelles, spontanes Teilen von Dateien. Die Prinzipien lassen sich breit übertragen.

s3cmd für Uploads in Cloud-Storage verwenden

s3cmd ist ein ausgereiftes, funktionsreiches Python-Werkzeug für die Interaktion mit Amazon S3 und S3-kompatiblen Object-Storage-Diensten wie MinIO, Wasabi, Backblaze B2 und anderen.

s3cmd installieren

Verwenden Sie eine gepflegte Python-3-Laufzeitumgebung. Wenn pipx⁠ installiert ist, halten Sie s3cmd von den Python-Paketen Ihres Systems isoliert:

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

Überprüfen Sie die Installation: s3cmd --version sollte 2.4.0 oder neuer anzeigen.

Zugangsdaten konfigurieren

Führen Sie den interaktiven Konfigurationsassistenten aus:

s3cmd --configure

Sie werden nach Ihrer Access Key ID, Ihrem Secret Access Key, der Standardregion sowie Ihren Einstellungen für Verschlüsselung und HTTPS gefragt. Die Einstellungen werden in einer Datei namens .s3cfg in Ihrem Home-Verzeichnis gespeichert. Ziehen Sie in automatisierten Umgebungen Umgebungsvariablen (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY und AWS_SESSION_TOKEN für temporäre Zugangsdaten) oder IAM-Rollen in Betracht, statt Schlüssel in der Konfigurationsdatei zu speichern. Legen Sie die Bucket-Region mit --region oder mit bucket_location in .s3cfg fest; AWS_DEFAULT_REGION konfiguriert s3cmd nicht.

Upload-Beispiele

# 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/"

Für große Dateien optimieren

Für Uploads großer Dateien unterstützt s3cmd Multipart-Uploads, die die Datei in kleinere Chunks aufteilen.

# 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/"

transfer.sh zum schnellen Teilen von Dateien verwenden

transfer.sh bietet eine einfache Möglichkeit, Dateien schnell von der Kommandozeile aus zu teilen. Zwar gab es öffentliche Instanzen, doch das Projekt empfiehlt inzwischen vor allem das Selbst-Hosting, um Zuverlässigkeit zu gewährleisten.

Eine eigene Instanz von transfer.sh betreiben

Sie können transfer.sh problemlos mit Docker betreiben. Der folgende Befehl startet eine temporäre Instanz, die Dateien in /tmp im Container ablegt:

# 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/

Dieses Wegwerf-Beispiel ist anonym und ausschließlich an Loopback gebunden. Verwenden Sie nicht vertrauliche Testdateien; richten Sie Authentifizierung und HTTPS ein, bevor Sie eine Instanz für andere Nutzer freigeben. Für dauerhaften Speicher binden Sie ein Host-Verzeichnis an /tmp im Container ein (z. B. -v /path/on/host:/tmp). Weitere fortgeschrittene Konfigurationen finden Sie in der Dokumentation zu transfer.sh.

Eine Datei über Ihre Instanz teilen

Sobald Ihre Instanz läuft (ersetzen Sie bei Bedarf localhost:8080):

# 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

Praktische öffentliche Alternativen

Wenn Selbst-Hosting für ein schnelles, einmaliges Teilen nicht praktikabel ist, bieten mehrere öffentliche Dienste ähnliche Funktionen:

# 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

Prüfen Sie vor der Nutzung die aktuellen Aufbewahrungsgrenzen und Nutzungsbedingungen auf file.io⁠ und temp.sh⁠. Senden Sie keine vertraulichen Dateien an einen anonymen öffentlichen Dienst; eine nicht erratbare Download-URL ist keine Zugriffskontrolle.

Ihre CLI-Uploads absichern

Beim Automatisieren von Dateiübertragungen hat Sicherheit oberste Priorität:

1. HTTPS verwenden: Bevorzugen Sie stets HTTPS-Endpunkte (s3cmd verwendet standardmäßig HTTPS), um Zugangsdaten und Daten während der Übertragung zu schützen. Vermeiden Sie einfaches HTTP.
2. Sensible Daten verschlüsseln: Für serverseitige Verschlüsselung verwenden Sie s3cmd --server-side-encryption (SSE-S3) oder --server-side-encryption-kms-id KEY_ID (SSE-KMS); das Objekt wird nach dem Eintreffen vom Anbieter verschlüsselt. s3cmd --encrypt ist das Gegenteil: Es handelt sich um clientseitige GPG-Verschlüsselung, die fehlschlägt, sofern nicht gpg_command und gpg_passphrase in .s3cfg gesetzt sind. Eigenständige Tools wie age oder gpg decken denselben clientseitigen Bereich ab.
3. Zugangsdaten sicher verwalten: Vermeiden Sie es, Access Keys oder Secrets fest in Skripten zu hinterlegen. Verwenden Sie Umgebungsvariablen, dedizierte Tools für die Verwaltung von Secrets (etwa HashiCorp Vault) oder IAM-Rollen (für Cloud-Umgebungen wie AWS EC2), die temporäre Zugangsdaten mit minimalen Rechten vergeben. Nehmen Sie Dateien namens .s3cfg nicht in die Versionsverwaltung auf.
4. Least Privilege anwenden: Konfigurieren Sie IAM-Richtlinien oder Bucket-Richtlinien so, dass nur die notwendigen Berechtigungen erteilt werden (z. B. s3:PutObject für Uploads, aber nicht s3:DeleteObject, wenn kein Löschen erforderlich ist). Schränken Sie den öffentlichen Zugriff ein, sofern er nicht absolut notwendig ist. Ziehen Sie Bucket-Richtlinien in Betracht, die Verschlüsselung beim Upload erzwingen.
5. Ratenbegrenzung nutzen: Verwenden Sie bei Massen-Uploads Optionen zur Ratenbegrenzung (s3cmd --limit-rate=1M für 1 MiB/s, rclone --bwlimit 1M), damit Netzwerkverbindungen nicht ausgelastet und API-Ratenlimits nicht erreicht werden. Implementieren Sie in Skripten einen exponentiellen Backoff, wenn Fehler durch Ratenbegrenzung auftreten (etwa HTTP 429).

Mit systemd-Timern automatisieren

Auf modernen Linux-Systemen bieten Timer von systemd eine robuste Alternative zu cron für die Zeitplanung von Aufgaben. Sie holen verpasste Läufe nach (z. B. wenn der Server ausgefallen war) und lassen sich besser in das Logging integrieren.

So richten Sie mit s3cmd einen täglichen Backup-Upload ein:

1. Erstellen Sie die Service-Unit-Datei /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. Erstellen Sie die Timer-Unit-Datei /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. Erstellen Sie das Backup-Skript /opt/scripts/backup-upload.sh (stellen Sie sicher, dass es ausführbar ist: chmod +x /opt/scripts/backup-upload.sh, und dass es dem Benutzer backup gehört: 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. Aktivieren und starten Sie den Timer:

# 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

Denken Sie daran, die Log-Rotation (z. B. mit logrotate) für /var/log/backup-upload.log zu konfigurieren.

Häufige Probleme beheben

Transloadit für Web- und Mobile-Uploads einsetzen

CLI-Tools sind serverseitig und in der Automatisierung stark. Uploads direkt aus Webbrowsern oder mobilen Anwendungen erfordern jedoch andere Lösungen, die Netzwerkunterbrechungen abfangen, Fortschritt zurückmelden und Fortsetzbarkeit bieten.

Hier kommt der Robot /upload/handle von Transloadit ins Spiel. Er ist speziell für robuste clientseitige Uploads ausgelegt.

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

Sie können diesen Robot mit Frontend-Bibliotheken wie Uppy (unserem vielseitigen Dateiuploader) oder mit jedem Client kombinieren, der das tus-Protokoll für fortsetzbare Uploads⁠ unterstützt. Diese Kombination bietet Funktionen wie das Pausieren und Fortsetzen von Uploads, automatische Retries und Fortschrittsanzeigen in Echtzeit und verbessert so die Nutzererfahrung in Anwendungen, die Ihre Kunden nutzen.

Viel Spaß beim Hochladen!