Strumenti di trasferimento file Linux: opzioni CLI e browser

Su Linux, il miglior strumento di trasferimento file dipende dal fatto che tu stia spostando file tra le tue macchine (rsync, scp, sftp) o inviando a qualcuno fuori dal tuo controllo (servizi via browser come HexaTransfer). Per copie bulk server-server, rsync -avP --partial è il cavallo da lavoro. Per consegna ad hoc a un destinatario non tecnico, un URL da un servizio via browser batte il chiedergli di installare un client SSH. Gli ambienti desktop Linux (GNOME, KDE) supportano anche SMB, WebDAV e la navigazione SFTP nativamente tramite il file manager.

I classici della CLI

scp — copia sicura su SSH. Semplicissimo:

scp filegrande.tar.gz user@server:/home/user/
scp -r cartella/ user@server:/path/

Nessuna ripresa al fallimento. Va bene per reti affidabili, fastidioso su quelle instabili. OpenSSH 9.0 (2022) ha cambiato il protocollo di default da SCP-su-SSH a SFTP — il comportamento è simile ma i casi limite differiscono.

rsync — sync incrementale con ripresa:

rsync -avP --partial source/ user@server:/dest/

Flag: -a modalità archivio (preserva permessi, tempi, symlink), -v verboso, -P progresso + --partial (mantiene il file parziale al fallimento). --bwlimit=50000 limita la banda a 50 MB/s se sei su un link condiviso.

Per root di origine e destinazione identici, rsync trasferisce solo i byte modificati nelle esecuzioni successive — enorme risparmio di tempo su trasferimenti ripetuti.

sftp — trasferimento file interattivo basato su SSH. Usalo come un vecchio client FTP:

sftp user@server
> put filegrande.tar.gz
> get qualchefile.txt

rclone — come rsync ma per provider cloud. Supporta S3, Google Drive, Dropbox, OneDrive, Backblaze B2 e decine di altri. Ottimo per upload scriptati all'object storage:

rclone copy local/cartella remote:bucket/path -P

Opzioni via browser per destinatari non tecnici

Non ogni destinatario di file ha chiavi SSH. Per invio a giornalisti, clienti o familiari, l'URL di un servizio di trasferimento è quello che funziona:

| Servizio | Max gratis | Crittografia | Linux-friendly | |---|---|---|---| | HexaTransfer | 10 GB | End-to-end AES-256-GCM | Sì (qualsiasi browser) | | WeTransfer | 2 GB | TLS | Sì | | SwissTransfer | 50 GB | TLS | Sì | | Proton Drive Share | 1 GB | End-to-end | Sì | | Tresorit Send | 5 GB | End-to-end | Sì |

Firefox e Chromium su Linux gestiscono entrambi con competenza gli upload grandi. Le performance di upload di solito corrispondono all'hardware e all'uplink, non al browser.

Strumenti stessa rete dal desktop

GNOME Files (Nautilus): Connetti al server > smb://, sftp://, ftp://, dav://. Monta il remoto come se fosse locale. Va bene per sfogliare occasionalmente.

KDE Dolphin: stessa capacità, UX leggermente diversa. Supporta gli stessi protocolli.

smbclient — SMB da riga di comando per script:

smbclient //server/share -U user

sshfs — monta un filesystem remoto su SSH:

sshfs user@server:/remote/path ~/mnt/remote

Utile quando un'app si aspetta un percorso locale.

Regolazione della velocità di trasferimento su Linux

Lo scaling della finestra TCP di default di Linux gestisce bene i trasferimenti ad alta banda, ma alcune distro hanno impostazioni conservative. Per trasferimenti su link a lunga distanza (alta latenza, alta banda):

sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

Abilita il controllo di congestione BBR per un miglior throughput su link con perdite:

sysctl -w net.ipv4.tcp_congestion_control=bbr

Questi non servono sulle normali reti domestiche — ma se stai spostando dati tra datacenter o attraverso continenti, la differenza tra CUBIC di default e BBR può essere 2-3x.

Archiviazione: varianti di tar

tar -czf archivio.tar.gz cartella/          # gzip, veloce, compressione moderata
tar -cjf archivio.tar.bz2 cartella/         # bzip2, più lento, migliore compressione
tar -cJf archivio.tar.xz cartella/          # xz, il più lento, migliore compressione
tar --use-compress-program=zstd -cf archivio.tar.zst cartella/   # zstd, veloce e buon rapporto

Per Linux moderno, zstd batte gzip sia in velocità che in rapporto di compressione. Per distribuzione a destinatari non-Linux, mantieniti su .zip — usa zip -r archivio.zip cartella/.

Per suddividere un archivio enorme in blocchi:

tar -czf - cartella/ | split -b 2G - archivio.tar.gz.part_

Ricomponi con cat archivio.tar.gz.part_* | tar -xzf -.

Object storage come mezzo di trasferimento

Per carichi di lavoro che generano molti file o file enormi, trattare un bucket cloud come layer di trasferimento è più pulito di un servizio one-shot:

AWS S3: aws s3 cp file s3://bucket/path poi genera un URL presigned con aws s3 presign s3://bucket/path --expires-in 3600. Il destinatario riceve un download diretto a tempo limitato.

Cloudflare R2: API compatibile S3, nessun costo di egress. Usa la stessa CLI aws con un endpoint personalizzato.

Backblaze B2: b2 upload-file bucket file key poi b2 get-download-url-with-auth bucket key 3600.

MinIO: self-host un server S3-compatibile, emetti URL presigned dal tuo dominio.

Per sviluppatori che inviano artefatti di build, log o dump, questi sono meglio di un servizio di trasferimento general-purpose.

Server HTTP ad hoc

Per trasferimenti rapidi sulla stessa LAN:

python3 -m http.server 8000

Serve la directory corrente su http://tuo-ip:8000/. Il destinatario va all'URL, scarica. Utile tra il tuo laptop e una VM o telefono sulla stessa Wi-Fi. Non crittografato — va bene internamente, non per l'esterno.

Per HTTPS con un certificato auto-firmato:

python3 -c "import http.server, ssl; httpd = http.server.HTTPServer(('0.0.0.0', 8443), http.server.SimpleHTTPRequestHandler); httpd.socket = ssl.wrap_socket(httpd.socket, certfile='cert.pem', server_side=True); httpd.serve_forever()"

caddy file-server lo fa pulitamente con HTTPS automatico se hai un dominio vero.

Strumenti P2P

Magic Wormhole (wormhole):

wormhole send filegrande.tar.gz
# stampa un codice tipo 7-crossover-clockwork
# il destinatario esegue: wormhole receive 7-crossover-clockwork

Crittografato end-to-end, funziona attraverso NAT via un server di rendezvous. Ottimo per trasferimenti diretti one-shot.

croc (di schollz): simile a wormhole, singolo binario, multipiattaforma. Popolare nella community homelab.

Sono peer-to-peer ma instradano ancora attraverso server di rendezvous per l'attraversamento NAT — la crittografia è E2E, il percorso no.

Crittografia a riposo prima dell'upload

Per flussi di lavoro extra paranoici, cripta l'archivio prima di inviarlo attraverso qualsiasi servizio:

gpg --symmetric --cipher-algo AES256 filegrande.tar.gz

Produce filegrande.tar.gz.gpg. Il destinatario decripta con gpg --decrypt. Condividi la passphrase fuori banda.

Oppure usa age, un'alternativa moderna:

age -p -o crittografato.age testo.tar.gz

Con servizi di trasferimento crittografati E2E come HexaTransfer, questo doppio wrapping è di solito non necessario — ma per modelli di minaccia a livello di stato, bretelle e cintura ha senso.

Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.