RCLONE è un strumento open source, inspirato a rsync, creato in origine da Nick Craig-Wood, nato dallo stress per il rumore e i costi energetici derivanti dalla localizzazione di server presso casa, che lo hanno spinto a verificare come fruttare il Cloud Storage. Lo sviluppo di RCLONE come software open source inizia nel 2012 con il nome Swiftsync. Attualmente è un progetto molto maturo, affidabile ed impiegato in molti modi.
In questo articolo, non spiegherò i dettagli su come configurare un repository remoto da utilizzare con RCLONE (nato per aiutare a realizzare backup in Cloud Storage), ma piuttosto fornirò gli spunti su come impiegare questo strumento.
RCLONE riesce a gestire, in modalità trasparente per l’utente, diversi backend storage come Amazon S3, Google Drive, Dropbox, OneDrive di Microsoft, ecc. Questo è un primo aspetto di notevole importanza poiché, dal punto di vista sistemistico, fornisce una facilitazione in termini di transizione e gestione nei cambiamenti, consentendo il cambio di Cloud Storage con un minimo impatto operativo/economico all’interno della propria infrastruttura IT.
Scenario
Ipotizzando di impiegare Amazon S3 per un certo periodo, a seguito dell’analisi dei costi, il management chiede di passare ad una piattaforma Google o Microsoft, in tal caso il lavoro richiederà pochi minuti per:
- configurare un il nuovo repository impiegabile da RCLONE
- adeguare gli script o porzioni di codice al fine di impiegare il nuovo repository. Teoricamente questo tempo potrebbe essere nullo nel caso si impiegasse lo stesso identificativo per il nuovo repository e si usasse un identificativo differente per quello precedente
- trasferire i file dal vecchio repository al nuovo. Questa attività è fortemente dipendente dalle dimensioni di dati coinvolte alla migrazione
Definire correttamente un politica di gestione complessiva dei dati, intesi come file posizionati sul filesystem, può fare la differenza in varie fasi: come cambio gestore di servizi, disaster recovery e business continuity.
Un altro aspetto molto importante è la sicurezza con sui viene gestito il tutto. Il canale preferenziale che viene impiegato con moltissimi backend Cloud Storage è HTTPS.
Ciò garantisce un canale punto-punto tra l’istanziatore della comunicazione (RCLONE) e il fornitore di servizio (i.e.: Google Drive), che consente di avere un trasferimento dati su Internet protetto perché cifrato. A questa sicurezza possono essere aggiunti ulteriori livelli di protezione come:
- configurare l’autorizzazione di accesso al Cloud Storage, tramite le credenziali associate ad RCLONE, da un insieme limitato di indirizzi IP. L’accesso sarebbe limitato solo da IP pubblici sotto il proprio controllo
- limitare il range di indirizzi IP abilitati, configurando RCLONE ad impiegare obbligatoriamente un proxy HTTPS. In questo modo i rischi sull’accesso non autorizzato sarebbero fortemente limitati
RCLONE è uno strumento nato per gestire dati in Cloud Storage.
Impieghi
Conservare archivi che rappresentano backup di dati o di ambienti (Virtual Machine) in un Cloud Storage per risparmiare sul consumo di spazio in locale e garantire un’area di custodia accessibile nel tempo e nello spazio; ad esempio per gestire politiche di disaster recovery o trasferimento dati tra sedi in modo controllato e sicuro.
In questo caso il comando da impiegare è sicuramente il seguente:
rclone copy -flags- -sorgente- -destinazione-
Segue un esempio di script bash per realizzare questa attività, con una notifica via email dell’operatività nell’esecuzione di questa attività di backup:
#!/bin/bash PATH=/bin:/usr/bin:/sbin:/usr/sbin rclone --log-file=/tmp/copiabackupsugsuite.txt copy /backup/ gdrive:miobackup if [ $? != "0" ] then cat /tmp/copiabackupsugsuite.txt |mail -s "Failure - COPY backup on gsuite" assistenza@maurosalvia.it else cat /tmp/copiabackupsugsuite.txt |mail -s "Successful - COPY backup on gsuite" assistenza@maurosalvia.it fi rm /tmp/copiabackupsugsuite.txt
In questo esempio è stata impiegata un’opzione di RCLONE (–log-file) che consente di avere un report sull’operatività del comando, per ottenere un riepilogo sulla corretta esecuzione dell’attività di backup.
Nel caso in cui fosse necessario un accesso all’incontrario si potrebbero impiegare RCLONE nel seguente modo:
$ rclone ls gdrive:miobackup/ file1.pdf ... ... $ rclone copy gdrive:miobackup/file1.pdf /tmp
Questa attività non necessariamente dev’essere eseguita sul server di origine da cui sono stati copiati i file, ma anche dal client RCLONE localizzato in un altro server ubicato anche in un altro luogo. Questo aspetto non è da trascurare, perché in genere la banda di trasferimento offerta dai provider di Cloud Storage è maggiore rispetto ad altre soluzioni proprietarie, specialmente se i propri server sono localizzati in datacenter.
Un esempio di impiego di questo meccanismo potrebbe essere i seguente:
Un’azienda ha dati salvati in archivi generati in diversi datacenter A, B e C. Questi archivi non vengono conservati nei datacenter, ma vengono spostati in uno o più Cloud Storage. Per una corretta gestione delle politiche di backup devono essere eseguite delle attività di validazione degli archivi, con ripristino e procedure particolari di test su un’area di testing realizzata nel datacenter D. Quest’attività di validazione potrà essere eseguita in qualsiasi momento, senza coinvolgere in alcun modo i datacenter di origine dei dati (A, B, C). Potrebbero essere eseguiti anche in modalità parallela ed in datacenter differenti: D1, D2, D3, ecc.
Un impiego diverso di RCLONE potrebbe essere quello di usare costantemente lo Cloud Storage come area di produzione ove accedono contemporaneamente dei propri applicativi da luoghi diversi ed ambienti diversi.
In questo caso il comando da impiegare è:
rclone mount -flags- -sorgente- -destinazione-
Un esempio di utilizzo di questo comando è il seguente:
rclone --vfs-cache-mode writes mount --daemon remoto:sottocartella /dropbox
Ipotizzando di avere un file di configurazione come il seguente:
#/root/.config/rclone/rclone.conf [remoto] type = dropbox chunk_size = 140M token = ...
In questo modo sul server sarà disponibile una cartella di Dropbox da impiegare per i nostri applicativi ( i.e. server di cartelle condivise, web application, ecc).
Se volessimo che la cartella si montasse automaticamente all’avvio del server si potrebbe realizzare un servizio impiegato da systemd, ad esempio:
# /etc/systemd/system/rclone.service [Unit] Description=Rclone VFS Mount After=network-online.target [Service] User=root Type=simple ExecStart=/usr/bin/rclone --vfs-cache-mode writes mount remoto:sottocartella /dropbox --config /root/.config/rclone/rclone.conf --quiet ExecStop=/bin/fusermount -u /dropbox Restart=on-abort RestartSec=5 StartLimitInterval=60s StartLimitBurst=3 [Install] WantedBy=default.target
A questo punto sarà sufficiente eseguire i seguenti comandi per abilitare ed attivare il servizio:
systemctl enable rclone.service systemctl daemon-reload systemctl start rclone.service systemctl status rclone.service
Se tutto è OK allora verifichiamo con il comando ls l’esistenza del contenuto nella cartella /dropbox ed usiamo il comando df -h per vedere quanto spazio abbiamo a disposizione, grazie alla partizione remota montata con il comando RCLONE:
~# df -h ... remoto:sottocartella 2,1T 319G 1,7T 16% /dropbox
Non dimentichiamoci di verificare se il servizio funzioni sempre correttamente. Nel caso precedente veniva evidenziato il tutto dalla notifica via email. E adesso? Semplice, basta usare adeguatamente uno strumento di monitoraggio.
Ad esempio con checkmk è possibile creare un check locale che esegua un test sull’accessibilità ad un particolare file, localizzato all’interno della cartella di /dropbox:
#/usr/lib/check_mk_agent/local/checkdropboxmount
#!/bin/bash
if [ -f /dropbox/montato ]
then
echo "0 Dropbox_folder_mounted - Service OK"
else
echo "2 Dropbox_folder_mounted - Service DOWN"
fi
