Premessa: non possiedo la minima informazione circa le novità che Veeam introdurrà nelle prossime versioni di Veeam Backup & Replication, questo post è completamente frutto di mie supposizioni.
No, questa volta non vi sto per parlare di una nuova funzione di Veeam; il nome “VeeaMover” è nato durante l’ultimo Veeam User Group tenutosi lo scorso Dicembre a Milano.
Parlando con alcuni utilizzatori di Veeam Backup & Replication, uno dei limiti riconosciuti da molti era l’impossibilità di inviare i file di backup contemporaneamente in due destinazioni differenti.
Da questa discussione ho tentato di derivare una piccola descrizione di come secondo me potrebbe essere risolto in modo elegante questa richiesta, integrandola direttamente nel prodotto invece di affidarsi come si fa ora a software esterni di replica.
VeeaMover diventerebbe il 4° componente della soluzione modulare adottata da Veeam col rilascio di VBR 6, in aggiunta a console, proxy e repository. Idealmente potrebbe essere installato sullo stesso server che funge da repository, ma come gli altri moduli il suo posizionamento potrebbe essere deciso.
La sua funzione consisterebbe nel leggere i file di backup di un repository e replicarli verso uno o più repository (o share di rete) remoti. Tutta una serie di opzioni regolerebbero le modalità di questa replica. Una prima lista di opzioni che dovrebbe idealmente avere potrebbero essere:
– invio verso più repository remoti contemporaneamente (hub and spoke)
– selezione del livello di compressione
– gestione del consumo di banda e degli orari in cui non operare
– gestione di una retention differente rispetto al repository originario (ad esempio conservare 180 giorni di backup mentre il repository primario ne conserva 30)
– possibilità di creare copie di backup escluse dalla retention come storico
– possibilità di cifrare i backup salvati remotamente (secondo me molto più importante rispetto al poter cifrare i backup locali, che se cifrati richiederebbero poi maggior tempo durante i restore)
Perchè dovrebbe farlo Veeam e non dovremmo andare avanti a usare software di terze parti? Per due motivi fondamentali secondo me: innanzitutto, la gestione dello schedulatore. Il Veeam server già possiede ottime possibilità di gestire la concorrenza dei job e la loro concatenazione. Un “Mover Job” potrebbe essere concatenato al suo job di backup, e sfruttare i controlli di consumo di banda che già sono in essere.
Ma il motivo fondamentale, che fin dall’inizio mi ha portato a pensare a questo componente, sarebbe la possibilità di usare i backup di tipo Reverse Incremental anche in situazioni “critiche” come appunto le repliche remote. Questo tipo di backup è di gran lunga il più efficiente per risparmiare spazio su disco e al tempo stesso garantire restore e instant recovery veloci. Ma il fatto che l’ultimo file di backup venga costantemente aggiornato e modificato crea spesso problemi con i software di replica, che vedono questo file come fosse del tutto nuovo. Un sistema di replica direttamente integrato in Veeam saprebbe invece identificare quali blocchi sono stati aggiornati rispetto alla precedente esecuzione del backup (d’altra parte è stato lui a scriverli!) e replicare solo questi blocchi. Così come per i proxy, si potrebbe ipotizzare di avere su copie geografiche due Mover, con quello locale che invia solo i blocchi modificati, e quello remoto che si preoccupa di riassemblarli nel reverse incremental.
Se qualcuno di Veeam sta leggendo, fateci un pensiero! 🙂