Re: backup KVM
In data venerdì 05 novembre 2010 15:25:18, dea ha scritto:
> In attesa di fornirvi un report sull'incremento (spero) prestazionale
> dell'uso di una MTU "jumbo" su storage via ISCSI...
> ... ritorno al solito problema.
>
> Riuscire a fare un backup "efficiente" di macchine KVM.
>
> Me le sono studiate tutte.. ed alla fine siamo sempre alle solite..
> servirebbe un DD che supporti una funzione differenziale, basata su un
> file di hash (relativo al full).
>
> Xdelta non va bene.. fa comunque riferimento al FULL (deve quindi averlo "a
> disposizione"), se ci fosse un file di hash (che contiene l'hash di ogni
> blocco) si potrebbe generare un diff relativo al full senza averlo a
> disposizione e senza rileggere integralmente il full ogni volta per
> compararlo [utile perchè il full se ne sta al sicuro in luoghi tipicamente
> non raggiungibili dai server].
>
> Abbiamo acquistato un programma che fa esattamente così per Win$ e funziona
> davvero bene (può funzionare anche in raw su un device).
>
> Ora, mi sembra impossibile dover costruire un accrocchio per gestire in
> modo intelligente i backup delle macchine KVM (a me interessa il
> contenitore, cosa c'è dentro non è affar mio, quindi non posso fare il
> backup "dall'interno").
>
> Me le sono studiate tutte.. sono arrivato a questa soluzione paranoica:
>
> -) Metto in freeze gli LVM che voglio sottoporre a backup (snapshot LVM).
> -) Passo gli LVM congelati come "dischi di una macchina virtuale Win"
> (SIGH). -) Uso il programma di cui sopra per procedere.
>
> Ma è assurdo, non ha senso e non voglio farlo (non vorrei, sigh)
>
> Idee ??? Io le ho esaurite...
>
> Grazie
>
> Luca
presumo che siano comunque in freeze anche quando lo dovresti fare con
linux...
in ogni caso, penso che si potrebbe utilizzare sempre dd... io la vedo così...
vediamo se riesco a darti qualche idea... (non sono procedure che ho provato,
sono idee che mi sono venute leggendo la tua mail).
eseguire dd in un loop, dove ad ogni ciclo si leggono un certo numero di
blocchi (anche uno, a discrezione), si passa il risultato ad uno script che ne
calcoli l'hash e lo salvi in una tabella con l'indicazione del numero del loop
da cui l'ha generato. Ad ogni loop il pezzo scaricato lo puoi agganciare
all'immagine finale (che sarà poi la tua immagine FULL).
alla fine ti troverai un file immagine completa e un file di codici hash con
l'indice in cui si trova nel file generale...
al prossimo ciclo fai la stessa procedura in cui però confronti l'hash con
l'elenco degli hash della full, e alla procedura che unisce i pezzi passi solo
quelli con hash diverso. Ti troverai quindi un'immagine che è il backup
incrementale del primo backup...
naturalmente più immagini incrementali utilizzi, e più diventa complesso il
confronto degli hash, a meno che non nel file degli hash di quello incrementale
non copi anche i dati di hash che non sono cambiati, devi però mettere un
indicatore di quale immagine contiene quell'hash...
in pratica il file dovrebbe essere qualcosa del tipo:
id blocco id backup hash blocco
1 0 asdfasfo....
2 1 asdfasfo....
3 0 asdfasfo....
4 5 asdfasfo....
5 0 asdfasfo....
6 4 asdfasfo....
con id backup 0 intendi il full backup, con 1 il primo backup incrementale e
così via...
naturalmente per il ripristino devi usare tutte le immagini, potresti magari
scrivere una procedura che prendendo il full e tutti i parziali generi un
nuovo full, da usare poi per il ripristino...
questa cosa potrebbe anche essere un metodo per determinare se il processo
funziona...
fai un full, e alcuni incrementali dopo un po' di tempo...
li unisci in un nuovo full e lo confronti con un full generato dal primo
passaggio eseguito dopo l'ultimo incrementale... (spero di essermi
spiegato...)
naturalmente se tutto funziona i due full dovrebbero essere perfettamente
identici...
--
Gollum1
Tesssssoro, dov'é il mio tesssssoro...
Reply to: