My Crash Plan?

Sono passati più di tre anni da questo post e con tristezza devo ammettere che finora con grandissima mea culpa ho ripiegato su soluzioni artigianali (copiare i file su un hard-disk esterno). Si aggiunga che nelle ultime settimane il disco di sistema di WHS ha cominciato a sclerare: gli hard disk non sono più quelli di una volta! Quelli migliori al giorno d’oggi sono garantiti 3 anni, una volta cinque anni era lo standard.

Qualche giorno fa, solleticato da varie polemiche circondanti questo post ripreso da LifeHacker, ho deciso – rincuorato anche dagli esperimenti dello stesso Scott – di ritentare la fortuna con CrashPlan che offre tutte le feature che servono per un backup come serve a me. Nell’ordine:

  1. seeding: considerando che il materiale “vitale” occupa circa 1TB (foto e video), fare l’upload via rete di una tale quantità di dati è definitivamente qualificabile come stupido. Ci vorrebbero mesi e il mio ISP mi sbatterebbe fuori dall’universo. Il seeding permette di creare il backup iniziale su un HD esterno, importarlo sulla macchina di destinazione, e usare internet per il backup differenziale da quel momento in poi.
    Infatti:
    image
  2. personal cloud/buddy backup: anziché ripiegare su servizi online, permette di usare un mio secondo PC, dislocato geograficamente in maniera strategica, come destinazione di backup.
  3. computer adoption: mi piacerebbe far girare crashplan sul mio WHS, però l’HD esterno da 3TB ha problemi con il dock USB (non compatibile con drive > 2TB). Il computer adoption mi permette di fare il seeding da un PC e continuare con il backup differenziale da un altro PC (il verso contrario del seeding al punto uno)

In passato ho avuto diversi problemi a far parlare due PC via internet quando c’erano di mezzo dei firewall incazzosi. La nuova versione, aperta l’opportuna porta sul router di casa, sembra essere in grado di funzionare decentemente.

Ho dovuto saltare un po’ di ostacoli, ma ho trovato tutta la documentazione che mi serviva sul sito di crashplan. Nell’ordine:

Nei prossimi giorni porto il seed a destinazione e vedo come va. Se sono soddisfatto potrei prendere in considerazione anche il loro servizio cloud da 3$ al mese per unlimited storage; l’unica limitazione è che il seeding è limitato a 1TB e sinceramente fare l’upload di 400GB non mi fa impazzire: spero di convincerli.

-quack

UPDATE (21.11.2012, 2:49PM PST): portato il seed a destinazione sono cominciati i guai.

Prima di tutto, dopo una scansione interminabile (100mila file non dovrebbe richiedere tanto) mi dice che ci sono 38GB di dati da sincronizzare. Ma io 38GB di file non li ho neanche toccati, anzi mi aspettavo di ricevere l’informazione che il backup è identico.

Dopodiché finita l’interminabile scansione, il crashplan service è crashato. Adesso continua a crashare in continuazione ogni dieci minuti. Sinceramente l’idea di avere un’app come CrashPlan è di essere in pace con se stessi. I crash ci possono pure stare, ma al primo backup differenziale dicono estremamente male. Sconsolato tocca pensare ad un’altra soluzione….

UPDATE (28.11.2012, 3:16PM PST): Ho contattato Crashplan tramite Twitter; devo dire che mi fa piacere vedere aziende che hanno il bug DB interfacciato con i social network e mi hanno spiegato come risolvere il problema del crash del servizio (alcuni setting della JVM sotto-dimensionati di default). Ho riprovato il seeding e questa volta è andato tutto bene; si aggiunga che giorni fa c’era un’offerta da black friday in cui offrivano il servizio di backup cloud con uno sconto fortissimo, inizialmente 100% e decrementava di qualche punto % ogni due ore. Ho pagato la modicissima cifra di 1.20$ per tutto l’anno e a questo punto ho ordinato anche il servizio di seeding deciso a backuppare online solo lo stretto indispensabile anche in virtù del fatto che la versione plus di CrashPlan permette di definire diversi backup set (nel mio caso: online, offsite e onsite). Aggiungerò un disco da 3GB al mediacenter che userò come backup onsite per i file meno vitali (praticamente la mia collezione di DVD rippati: doverli ri-rippare mi verrebbe a costare molto di più del costo di un hard-disk da 3TB). E con questo sono apposto.

Ma nel frattempo….

Pubblicato lunedì 19 novembre 2012 alle 11:33 PM - 7 commenti so far
Archiviato in: Backup

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

Pubblicato giovedì 16 dicembre 2010 alle 9:22 PM - 8 commenti so far
Archiviato in: Backup

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:

OffsiteDiagram

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

Pubblicato martedì 2 novembre 2010 alle 4:52 AM - 6 commenti so far
Archiviato in: Backup

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

Pubblicato mercoledì 20 ottobre 2010 alle 11:40 PM - 2 commenti so far
Archiviato in: Backup

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

Pubblicato martedì 12 ottobre 2010 alle 10:54 PM - 23 commenti so far
Archiviato in: Software, Backup