A Ovest Di Paperino

Making sense of VAIL

Non è passato molto tempo dall’annuncio della rimozione di una delle feature cruciali di WHS, ovvero il drive extender, ed ora che si son calmate le acque e ho avuto modo di riflettere ho personalmente ridimensionato il dramma.

I tre compiti in cui WHS eccelle sono:

1. il backup ottimizzato di tutti i PC di casa, feature che non ha pari in altri prodotti simili e che rimarrà intatta in VAIL
2. i folder duplicati via DE: questa feature garantisce che i dati più preziosi vengano copiati su due dischi fisici diversi
3. la facile estendibilità del sistema: aggiungere/sostituire un drive dati è facile, ovvero implementa un sistema di spanning molto pratico

Mi son fatto un giro alla ricerca di alternative, con ZFS la più succolenta tecnologicamente parlando, fuori e dentro Windows e questi sono alcuni progetti interessanti divisi in tre gruppi: Windows, ZFS, altro.

Windows

Il lato positivo di prodotti per Windows è che sono utilizzabili anche con VAIL senza perdere l’uso del backup ottimizzato.

• FlexRAID è un RAID software (RAID4 o RAID6) abbastanza interessante che ha il suo punto di forza nella flessibilità dello scegliere quali folder usare per i dati e quali usare per la parità. Una demo è visibile in questo video.
• Disparity simile al precedente ma un po’ più spartano.

ZFS

ZFS è un file system open source alquanto interessante, che supporta un sacco di feature interessanti che si prestano perfettamente a situazioni di backup con molti dischi disomogenei, ecc.

• FreeNAS è forse la più famosa delle alternative a WHS e la cui ultima versione in beta supporta una delle nuove feature di ZFS (data deduplication) utile per il supporto dei backup dei PC. Basato su BSD mi è sembrato alquanto incasinato
• NexentaStor è basato su OpenSolaris e nella versione community gratuita supporta fino a 18TB di dati. È un prodotto pensato come NAS
• OpenSolaris / Oracle Solaris Express 11 I sistemi operativi duri e puri, in cui tutta la configurazione va fatta a mano

Altro

Si parla tanto di port nativo di ZFS per Linux. Il fatto che nessuna distro, per motivi di licenza, può includere ZFS rende le cose un po’ più complicate. Però per Linux esistono un altro paio di alternative a WHS

• Greyhole / Amahi ha un sacco di feature molto simili a WHS. L’ultima release però si chiama “it should work” e la cosa non mi piace. In questa pagina alcune indicazioni per chi vuole migrare da WHS a Greyhole/Amahi (Greyhole è il nome della tecnologia di duplicazione/pooling, Amahi è il nome di una distro costruita su misura per un NAS basato su GreyHole).
• UnRAID usa l’approccio RAID-4 e la versione base (gratuita) supporta fino a tre drive fisici
• OpenFiler un’altra distro Linux specifica per NAS che non è ben chiaro cosa supporti e come

Ben pochi poi conoscono che sin dalle prime versioni di Windows è possibile creare dei veri e propri RAID/pool via software tramite l’uso dei Dynamic Disks. Per un attimo mi era balenata l’idea di usare una configurazione RAID-5 software ma la mancanza di flessibilità, ovvero la non possibilità di aggiungere un drive al pool e rigenerare l’array, mi ha fatto scartare questa soluzione. Tra l’altro il RAID-5 via software non è proprio affidabilissimo a causa del Write Hole.

In questi giorni sto provando Nexenta Community su bare metal. Se mi convince, e da quello che ho visto ci sarebbe da leccarsi i baffi, proverò a configurarlo facendolo girare su Hyper-V in modo tale da godere del migliore dei due mondi: avere Windows come piattaforma per tutti i servizi ormai irrinunciabili (condivisione scanner e stampante, servizio-rippa-tutto, PeoneFS, ecc) e uno storage fighissimo basato su Raid-Z.

-quack

Offsite backup–parte 4: finale?

I pezzi del puzzle e gli appuntamenti precedenti:

1. la prima parte era dedicata ai requirement generali
2. la seconda parte, dedicata ai punti fondamentali e ad una analisi delle possibili soluzioni
3. la terza parte a come ho risolto il problema del criptaggio dei dati
4. un intermezzo dedicato ad un piccolo problema con SSH

Questo post finale è dedicato al mettere insieme i vari pezzi che compongono la mia soluzione.

Hardware: un HD esterno Seagate con dock. Il vantaggio di tale soluzione è che ci sono dei dock con micro-Linux che potrebbero funzionare stand-alone ad un costo irrisorio per le funzionalità offerte. Ad ogni modo mi sono limitato ad usarlo come unità esterna collegata al PC offsite.

Software:

• OpenSSH, da installare in versione server sul server casalingo. Ovviamente va aperta l’apposita porta (22) sul firewall. Discusso in dettaglio al punto 3 di cui sopra.
• Un client SSH fatto a mano: non è pronto per il mondo in quanto c’è ancora qualche baco da sistemare, ma l’idea è di creare un client inossidabile. Gli altri client che ho provato hanno il difetto di disconnettersi senza avvertire.
• DeltaCopy, una versione grafica di RSync. Da installare lato client sul server casalingo e lato server sul PC offsite. Ho provato tante GUI ma questa seppur spartana ha tutte le feature che interessano: task scheduler integrato con quello di sistema e client SMTP che alla fine di ogni backup invia una mail dettagliata
• PeoneFS, vedasi punto due di cui sopra

Praticamente il PC offsite si collega via SSH al server casalingo. Nel collegarsi crea un tunnel-rovesciato sulla porta di RSync (873). Questo significa che la porta 873 sul server di casa sarà un tonnel alla stessa porta del server RSync sul PC offsite. Sul server casalingo ci gira il client RSync e PeoneFS; il client è configurato per fare il backup dal drive PeoneFS al server RSync ad una certa ora specifica di ogni giorno.

Sperando che un diagramma valga più di cento parole:

Possibili miglioramenti: rsync, per quanto sia molto efficiente nel trasferire spezzoni di file, non mi sembra sia altrettanto efficiente nel caso di confronto di directory molto ampie. Quando ci sono tantissimi file in ballo come nel mio caso un backup dura almeno un’ora. Sto pensando ad un modo di utilizzare il Remote Differential Protocol in combinazione con il Sync Framework per ottenere il migliore dei mondi possibili. Ma questo è un progetto per più di un weekend.

-quack

Offsite Backup–intervallo

Avevo promesso un post dedicato all’assemblaggio dei vari pezzi ma mi son scontrato con qualche difficoltà con OpenSSH a cui penso valga la pena dedicare questo post. La modalità SSH che mi interessa è quella senza password e cioè basata su keyfile per fare in modo che il client installato sul mio PC di test si collegasse automaticamente al server. Il keyfile in pratica sostituisce l’uso della password tramite una chiave privata RSA.

È stato un bagno di sangue ma ce l’ho fatta. In sintesi quello che ho scoperto. Ci sono due versioni di SSHWindows:

1. quella ‘ufficiale’ 3.81p-1 datata 9 Luglio 2004
2. quella derivata, 4.2p2-2, qualche anno più nuova

La prima ha un baco molto antipatico: non riconosce i permessi per Windows e si rifiuta, nonostante sia considerato un “warning” e non un errore, di caricare un keyfile senza i permessi settati correttamente; la cosa buffa è che settarli correttamente è impossibile. Il problema si scavalca installando la ‘nuova’ versione ma non è finita.

Sul lato server l’installazione di SSHWindows crea un servizio con permessi di LocalSystem. Questo previene la possibilità di impersonare l’utente desiderato usando il keyfile restituendo un errore di tipo “public key auth seteuid fails”. Cercando su Google e passando per tipi misteriosi che dichiarano che Windows 2003 non è un sistema multi user e blah blah blah mi son ficcato solo in vicoli ciechi. Ho provato invece a far girare il servizio OpenSSH con le credenziali di destinazione sperando che funzionasse al primo colpo. Un ulteriore intoppo, i permessi sbagliati nella cartella dei log, facilmente sistemabile.

Riassumendo i passi correttivi:

1. installare sshwindows in versione “derivata” su entrambi i lati della connessione
2. seguire il tutorial indicato in questa pagina per generare la chiave RSA
3. cambiare i permessi con cui gira il servizio OpenSSH
4. aggiungere l’utente desiderato al folder di log

Et voilà il gioco è fatto. Visto che sono riuscito a procurarmi ben due librerie diverse per .Net che consentono la connessione SSH, spero di trovare un ritaglio di tempo per creare un client customizzato da fare girare come un servizio alla stregua di PeoneFS. Nella prossima puntata metto tutti i pezzi insieme, ma garantisco che non sarà l’ultima. Ho in mente una versione due dell’accrocchio che… ssst…

-quack

Offsite Backup–parte 3: PeoneFS

Dove eravamo rimasti? Una buona alternativa all’encryption di RsyncCrypto, unico tool “compatibile” con l’algoritmo di Rsync, doveva essere farina del mio sacco. Ecco al mondo la versione “stabile” di PeoneFS.

Innanzitutto un po’ di teoria. Ci sono tanti algoritmi crittografici con svariati livelli di sicurezza. Per un backup offsite casalingo un algoritmo superveloce anche se poco sicuro è la migliore soluzione. Una classificazione piuttosto grossolana divide tali algoritmi in due macro-classi: crittografia a blocchi e crittografia a stream (non ho l’equivalente italiano a portata di mano). Questi ultimi si basano di solito sulla simmetria delle operazioni di XOR e sul fatto che un algoritmo XOR perfetto è impenetrabile (Vernam cipher) come dimostrato da Shannon in altri tempi: quest’ultimo si basa sul concetto di “password” infinita che però non ha nessuna implementazione pratica. Algoritmi più pratici come l’RC4 si basano su una password “infinita” pseudo-casuale genata da una normale chiave di testo o sequenza di byte. Come approssimazione è abbastanza buona, anche se comunque attaccabile: questo non è un problema per l’uso che di questo algoritmo ne va fatto. Io ho fatto una piccola ulteriore modifica personale per ottenere una maggiore velocità in cambio di un’ulteriore debolezza: la chiave invece di essere infinita ha un periodo di 64MB, che sono abbastanza per la tipologia di file interessata. Un’ulteriore debolezza intrinseca è il fatto che per tutti i file viene usata praticamente la stessa chiave; con l’RC4 è infatti consigliato l’uso di un nonce che però davvero non saprei per ora come implementare e se ne valga davvero la pena. L’obiettivo è di scoraggiare il ladro occasionale dallo sbirciare le foto del mio album di famiglia e – secondo la mia modesta opinione – l’obiettivo dovrebbe essere più che centrato (centratissimo?).

Lato pratico ho voluto creare un EXE portabilissimo anche se richiede l’uso di .Net 4. Si può lanciarlo in modalità di test o previo opportuno parametro chiederne l’installazione/disinstallazione come servizio. Nel primo caso non c’è bisogno di privilegi amministrativi, nel secondo l’eseguibile provvederà a richiedere un prompt UAC, autorilanciarsi/installare/eseguire/ritornare senza colpo ferire. Questa parte tecnica è risultata essere molto interessante in quanto sono riuscito a mantenere l’illusione che ad eseguire il compito è lo stesso processo mentre in realtà viene creato un processo figlio elevato e non-visibile che comunica con il padre via named-pipe ricreando l’output nel terminale del processo di partenza. Forse parlo arabo, ma ciò nonostante la cosa si è rivelata alquanto interessante. Tutta la configurazione infine avviene tramite un banale file di configurazione con cui è possibile “montare” più folder criptati. Il download è disponibile nell’apposita pagina.

Update. Dettaglio importante: oltre a criptare il contenuto dei file, il nome dei file e dei folder viene pesantemente offuscato sempre in maniera simmetrica. Ciò significa che se si copia un file dal folder criptato al folder originario lo stesso file apparirà in chiaro.

Nel prossimo (ultimo?) appuntamento racconterò come tutti i pezzi del puzzle si incastrano per creare l’offsite backup casalingo più spensierato che ci sia.

-quack

Offsite backup-parte 2

Segue la seconda parte della serie. La prima parte è qui.

Ho cercato in lungo ed in largo applicazioni che supportassero i seguenti requisiti:

1. supporto backup differenziale e parziale (ovvero se modifico una sola parte di un solo file, non backuppare tutti gli altri 200 e passa gigabait di dati). Questo si traduce più o meno con il supporto per server RSync
2. supporto per il criptaggio dei backup: significa che i file devono uscire dalla mia home network possibilmente già criptati; è preferibile che i nomi dei file vengano pure offuscati
3. leggero e veloce in quanto tutta la baracca deve girare su un Atom D510
4. possibilità di fare il seeding ovvero il bootstrap del backup verso un disco USB da portare nella locazione remota
5. che sia compatibile con il reverse tunneling SSH

Ho analizzato i seguenti prodotti:

• Duplicati, open source e gratuito. Per lo più scritto in C#; supporta una modalità differenziale/parziale anche se non RSync: la differenza è che l’operazione di restore è più lenta, ma è poco importante; scartata in quanto non implementa il punto 5. Interessante in prospettiva in quanto potrei metterci le mani e modificarlo a mio diletto e piacimento.
• Syncrify, commerciale ma gratuito per uso personale; se ben ricordo non supporta l’offuscamento dei nomi dei file.
• StoreGrid, commerciale: il server è gratuito mentre la versione pro del client ha costi accessibilissimi (30$). Purtroppo installa una quantità inverosimile di pacchetti: Apache, PHP, mysql e chissà quale altra roba. Scartato per il motivo 3.
• Amanda/Zmanda ha un approccio interessante al problema in quanto il backup server accede ai file del client e non viceversa. Purtroppo, pur credendo che in fondo in fondo sia compatibile con il requirement 5., non credo che sia una soluzione per i deboli di cuore come me
• QtdSync: una GUI open source molto ben fatta per RSync/windows con la possibilità di passare alcuni parametri RSync a mano; purtroppo niente encryption o similari supportate nativamente
• BackupAssist: commerciale, costosetto forse per una soluzione casalinga, ma in grado di soddisfare tutti i requirement di cui sopra. Versione trial per 30 giorni

Ho pertanto deciso di provare backup assist, collegando un disco esterno via USB ed iniziando il seeding: il risultato è stato disastroso dal punto di vista della velocità. 50MB/h significa che il prodotto è prettamente inusabile. Però ho notato che altro non è che una GUI intorno ad una versione particolare di RSync/Windows e RSyncrypto una utility a riga di comando sempre open source che implementa l’encryption AES e l’offuscamento dei nomi dei file in maniera trasparente. Credo che gli autori di backup assist abbiano cappellato alla grande in quanto da un Atom D510 mi aspetterei molto più di 50MB di AES ad ora.

Il prossimo step è di fare qualche test con Rsyncrypto e valutare di conseguenza: c’è infatti un’altra idea che continua a rimbalzare tra i due neuroni della mia scatola cranica ed è quella di scrivere un FS filter driver ad hoc risolvendo il problema numero 2. di cui sopra. Con Dokan anche un bambino può farlo (e persino in .Net anche se non saprei se azzardarmi). A quel punto qualsiasi soluzione basata su RSync o similari sarebbe più che buona, anche se ci sono 35$ di buoni motivi per preferire RSync ad un qualsiasi altro protocollo.

-quack