Backup regolari e offsite proteggono i dati critici da guasti hardware, ransomware e disastri locali. Ma sviluppatori, sysadmin e utenti esperti attenti alla privacy che gestiscono server headless o script pianificati non possono affidarsi al caricamento manuale tramite browser o app desktop.

Con il rilascio della CLI di Proton Drive (command line interface), puoi integrare la crittografia end-to-end (E2EE) zero-knowledge di Proton nell’automazione dei tuoi backup cloud: i tuoi script di backup e i flussi di lavoro shell pianificati.

Per usare la CLI in modo efficace è necessario comprenderne il ruolo. Questa guida spiega perché un’architettura di backup basata sulla CLI è superiore alla sincronizzazione continua in background, come le strategie di conflitto gestiscono le revisioni dei file e come pianificare backup offsite completamente crittografati su Linux, macOS e Windows.

Che cos’è un backup offsite e perché è importante?

Se il tuo backup risiede sulla stessa macchina dei tuoi dati, non è davvero un backup. L’hardware si guasta. Il ransomware crittografa tutto ciò che riesce a raggiungere, comprese le unità collegate. Un incendio, un’alluvione o un furto non distinguono tra il tuo disco principale e l’unità di backup che si trova proprio accanto.

La regola di backup 3-2-1 esiste per questo motivo: conserva almeno 3 copie dei tuoi dati, su almeno 2 supporti diversi, con almeno 1 copia offsite.

Quella copia offsite, che dovrebbe essere geograficamente separata dagli altri backup e dai dati principali, è la tua ultima linea di difesa, quindi deve trovarsi in un luogo che un guasto locale non possa raggiungere. Se risiede nel cloud, anche il fornitore del servizio non deve poterla leggere. È qui che entra in gioco la CLI di Proton Drive.

Perché crittografare i backup offsite?

Archiviare un backup offsite significa affidare i tuoi dati a terzi: un server remoto fuori dal tuo controllo, gestito da un’azienda la cui proprietà o le cui policy possono cambiare e la cui infrastruttura può essere oggetto di ingiunzioni giudiziarie o violazioni.

La crittografia end-to-end risolve questo problema. I tuoi file vengono crittografati sul tuo dispositivo prima di lasciarlo. Se il server cloud viene compromesso, non c’è nulla di leggibile per un attaccante, per il fornitore o per chiunque non possieda la tua chiave di decriptazione.

Proton Drive usa la crittografia end-to-end per impostazione predefinita per tutto ciò che viene caricato tramite le app desktop, le app mobile e la CLI. Il tuo backup offsite crittografato è protetto dalla stessa architettura zero-access che Proton ha sviluppato per Proton Mail, in base alle rigide leggi svizzere sulla privacy.

Capire la CLI di Proton Drive: scripting atomico vs sincronizzazione in background

La CLI funziona diversamente da un’app di sincronizzazione desktop:

Le app desktop e mobile (motori di sincronizzazione) vengono eseguite in modo continuo in background. Rilevano le modifiche ai file e copiano ogni aggiunta, modifica ed eliminazione nel cloud.

La CLI di Proton Drive (motore di esecuzione atomica) esegue un singolo comando, come upload, download o list, poi termina. Non monitora le cartelle locali né viene eseguita in background.

Perché una CLI atomica è la scelta giusta per la sicurezza e i backup

Un daemon di sincronizzazione continua rispecchia i tuoi dati, quindi non supera il test 3-2-1. Se un file viene eliminato localmente, per errore, a causa di un errore in uno script o di un ransomware, l’eliminazione raggiunge immediatamente il cloud. E se un attaccante viola il tuo sistema mentre il daemon è in esecuzione, potrebbe leggere i suoi token di sessione attivi.

La CLI risolve questo problema attivando backup periodici e pianificati. La richiami, viene eseguita, si arresta e lascia un’istantanea di ripristino sicura riferita a un momento preciso, su cui puoi fare affidamento se un file viene eliminato o danneggiato accidentalmente in locale.

Nota: la CLI non è di per sé una soluzione di backup completa. Sei comunque tu a decidere cosa sottoporre a backup, con quale frequenza, quante versioni conservare e come testare i ripristini.

Come le strategie di conflitto gestiscono i backup incrementali

Per scelta progettuale, la CLI ignora automaticamente i file identici non modificati per risparmiare banda. Tuttavia, quando un file è stato modificato localmente, devi indicare alla CLI come gestirlo usando le strategie di conflitto.

Evita di usare skip per i backup. Sebbene prevenga il lavoro duplicato, ignorerà completamente i file modificati. Scegli invece la strategia più adatta alle tue esigenze di conservazione:

--file-conflict-strategy create-new-revision (consigliata per i backup) carica il file modificato come nuova versione e ne conserva la cronologia. Il numero di versioni conservate dipende dal tuo piano e le versioni occupano spazio di archiviazione.

--file-conflict-strategy rename aggiunge un suffisso al nome del file modificato e conserva entrambe le copie.

--file-conflict-strategy replace sovrascrive il file precedente con quello nuovo. La versione precedente va persa.

--file-conflict-strategy skip ignora qualsiasi file già presente nel cloud, quindi le modifiche non vengono mai salvate (non consigliata per i backup).

Esempio di comando di caricamento incrementale:

proton-drive filesystem upload ./my-local-data /my-files/Backups/Daily \
--folder-conflict-strategy merge --file-conflict-strategy create-new-revision

Configurare un backup automatizzato e crittografato: guida passo passo

Cosa ti serve:

  • Un account Proton (gratuito o a pagamento; si applicano i limiti di archiviazione)
  • Il binario della CLI di Proton Drive per la tua piattaforma (Linux, macOS o Windows)
  • Un ambiente shell (Terminal, Bash, Sh, PowerShell)
  • Un pianificatore di attività per le esecuzioni automatiche: cron (Linux/macOS) o Task Scheduler (Windows)

Passaggio 1: accedi ed esegui un test manuale

Prima di configurare l’automazione, autentica il tuo dispositivo in modo interattivo:

proton-drive auth login

Come funziona l’autenticazione headless: quando esegui auth login su un server senza browser, ad esempio un VPS remoto o un nodo Linux domestico, la CLI stampa un URL di accesso. Aprilo su qualsiasi dispositivo con un browser, come il tuo laptop o il tuo smartphone, e completa l’accesso. Il server risulterà così connesso.

Suggerimento per server headless / cron: per i sistemi headless e automatizzati eseguiti tramite cron, è consigliabile usare pass come archivio delle credenziali. Impostalo con questa variabile d’ambiente:export PROTON_DRIVE_CREDENTIALS_STORE="pass"). I portachiavi standard del sistema operativo (libsecret / GNOME Keyring) dipendono da sessioni desktop GUI attive, che i job cron non hanno. Configurare pass evita problemi di sessione D-Bus.

Passaggio 2: scrivi lo script di backup

Crea uno script shell, ad esempio backup.sh, che definisce i percorsi di origine, gestisce i portachiavi ed esegue il caricamento:

#!/usr/bin/env bash
set -euo pipefail

# Define variables
LOCAL_DIR="/var/backups/data"
REMOTE_DIR="/my-files/AutomatedBackups"
export PROTON_DRIVE_CREDENTIALS_STORE="pass"

# Execute idempotent upload
proton-drive filesystem upload "$LOCAL_DIR" "$REMOTE_DIR" \
--folder-conflict-strategy merge \
--file-conflict-strategy create-new-revision \
--json > /var/log/proton-backup-$(date +%Y%m%d-%H%M%S).json

echo "Backup completed successfully at $(date)"

Passaggio 3: pianifica il backup con cron o i timer di systemd

Per eseguire questo backup ogni notte alle 02:00 con cron:

  1. Apri l’editor del crontab e aggiungi:
crontab -e
  1. Aggiungi la voce di esecuzione pianificata:
0 2 * * * /usr/local/bin/backup.sh >> /var/log/proton-backup.log 2>&1

Buone pratiche per i backup offsite automatici

Uno script funzionante è solo l’inizio. Queste tre abitudini mantengono il backup offsite completo, facile da monitorare e entro i limiti di archiviazione.

Testa il ripristino: Un backup senza un ripristino funzionante equivale a nessun backup. Tieni pronto uno script di ripristino, basato su proton-drive filesystem download, e testalo regolarmente in modo che funzioni quando si verifica un incidente.

Log in formati leggibili dalle macchine: Aggiungi --json ai tuoi script per generare log JSON strutturati. Puoi quindi analizzare lo stato dei job con jq o attivare un webhook quando un backup non riesce.

Rispetta il fair use: Non pianificare caricamenti ad alta frequenza, ad esempio ogni 60 secondi. Una pianificazione giornaliera o settimanale è sufficiente per i backup offsite.

Il tuo backup offsite, crittografato e automatizzato

I tuoi backup sono sicuri quanto il luogo in cui li invii. Con la CLI di Proton Drive, ogni processo notturno invia un backup offsite crittografato che nessuno può leggere tranne te. Non gli attaccanti, non il tuo provider di hosting, non Proton.

Ottieni la crittografia end-to-end, la protezione legale della legge svizzera sulla privacy e il codice open source sottoposto a verifica indipendente. Mantieni inoltre il pieno controllo della pipeline di backup: cosa viene eseguito, quando e per quanto tempo resta ogni versione.

La configurazione richiede pochi minuti. Scarica la CLI per Linux, macOS o Windows, esegui il primo backup manuale, poi pianificalo e non pensarci più.