Newsgroup: it.comp.os.linux.sys
Titolo: Backup VMs Xen 5.5 (che tormento)

Allora sono arrivato a delle chiarezze, ma non ancora ad una soluzione 
completa.
Il quadro e` 2 nodi Xen 5.5 con plurime NIC Gbit, dischi veloci e in 
RAID 10 con buona quantita` di spazio (piu` del doppio di quello 
utilizzato) con 5-6 VMs, prevalentemente Windows server e qualcuna Linux.
Per il disaster recovery posso fare delle copie e degli snapshot delle 
macchine virtuali anche spente (di notte non vengono usate se non per i 
backup) incrociandole fra i due nodi, cosi` da essere garantito in caso
di crash hw di un nodo o sw di una VM potendola riaccendere sull'altro.
Il problema e` quello del backup a livello di filesystem in modo da 
poter ripristinare velocemente i singoli files alla bisogna. Non sarebbe 
un problema in se' perche' facendo il backup dall'interno delle macchine 
virtuali come se fosssero fisiche, tutto sarebbe relativamente semplice, 
oppure ancora meglio sfruttando le funzionalita` di backup che mette a 
disposizione Xen 5.5 accoppiato a un sw che le sa sfruttare come Net 
Backup.
Ora il problema e` che io preferire (devo) usare un sw free come una 
birra perche' non ci sono i soldi per usarne un altro.
In quest'ottica stavo considerando di copiare dall'interno delle VMs
i filesystem delle varie macchine su un'altra che, ulteriormente ha 
attaccato un dispositivo di backup.
Ho visto un po' robocopy /copyall, rsync, crsync, DeltaData, Unison, ma 
non so se nessuno possa fare completamente al caso.
Il primo sembrerebbe una buona scelta per le macchine Windows perche' 
preserva attributi e ACL NTFS dei files, ma oltre a non sapere che ne
succede una volta che i files arrivano su un filesystem di destinazione 
diverso, non mi sembra che sia incrementale con la possibilita` di 
copiare solo gli aggiornamenti e le differenze come rsync, DeltaData e 
Unison, per cui ogni volta sarebbe un full di centinaia di GB di dati 
che non mi piace ne' per il tempo, ne' per il consumo energetico, ne' di 
disco.
Gli altri sarebbero tutti meglio da questo punto di vista, ma saranno in 
grado di conservare tutti gli attributi e le ACL NTFS delle macchine 
Windows? Insomma, ho un po' di dubbi e non so bene come fare a chiarirmeli.
Mi rendo conto che non e` del tutto OT (On Topic :-), ma comunque NTFS 
c'e` pure per Linux, anche se non so se sia abbastanza afffidabile (in 
ogni caso lo scriverci e` sempre accompagnato ad un disclaimer, anche se 
poi funziona).
Grazie ai rispondenti, saluti a tutti,
Andrea

 birra perche' non ci sono i soldi per usarne un altro.
Che problema c'e' ad usare il backup di windows (ntbackup) verso per es. 
un nas in rete?
--
Bye
Gianfranco Bartolini

 un nas in rete?
Una miriade?
Nel senso che ntbackup non l'ho mai visto funzionare in modo
affidabile, se
non dopo averci messo sopra BackupAssist, che, cosa molto positiva per
il
formato standard che ne risulta, lo usa sia per il backup sia, in modo
assoluto
ed esclusivo per il restore, pero`, anche se meno di molti altri,
costa soldi.
Che oltre a volere i dati su NAS li vorrei anche su nastro o altro
dispositivo
facilmente trasportabile e/o archiviabile (da portare in banca p.es.).
Col fatto che non potrebbe funzionare per fare il backup delle
macchine Linux.
In idea mi stavo orientando verso Bacula, che dovrebbe poter
funzionare sia per
le macchine virtuali Linux, sia per quelle Windows e se il sistema che
c'e` sotto
al server (obbligatoriamente Linux) vede il la libreria a nastri (o
LTO), allora lui
dovrebbe essere in grado di fare delle copie anche li` sopra.
L'ideale sarebbe pero` comunque che le macchine facesseo una copia dei
loro
filesystems sulla macchina di backup, la quale poi con Bacula li
salvasse su nastro,
in modo da averli disponibili in modo immediato su quella macchina,
senza dover
passare per un processo di restore da backup.
Mah? Boh? Chissa`?
Grazie comunque.

 salvasse su nastro,
Personalmente uso una tecnica simile, ovvero comprimo una copia dei
dati che mi interessano con Tar e Bzip2, li copio su di una macchina e
poi li trasferisco su nastro. Ovviamente faccio tutto questo per mezzo
di script ad hoc (all'epoca ho tentato di studiarmi la documentazione di
Bacula, ma ho desistito dopo le prime tre pagine)
Enrico

 passare per un processo di restore da backup.
Spazio permettendo sul server. Per questo parlavo di NAS inizialmente.
Di notte scheduli i processi di backup su NAS, di giorno con calma copi 
da NAS a tape.
--
Bye
Gianfranco Bartolini

On 10 Ago, 15:13, Enrico 'Henryx' Bianchi

Si`, fa quell'effetto. E' meno devastante andarsi a leggere i file di
configurazione
sotto /etc, piuttosto della documentazione (forse quella
documentazione non e`
fatta molto bene ;-)
Si`, col tarb(g)zippo o semplice zippo per le macchine Windoze mi
risolverei anche
i problemi dei permessi, attributi e ACL, pero` non potrei fare al
volo un ripristino
di un file e nemmeno versionare e/o aggiornare solo per differenza i
files gia`
presenti sulla macchina di destinazione e backup.
Andrea

Enrico 'Henryx' Bianchi ha scritto:

che ti ha fatto bacula? nel suo funziona...� parecchio macchinoso a mio 
avviso ma va...

 da NAS a tape.
Si`, funzionera` cosi`.
Rimane il problema della copia su NAS, nel senso che se ci voglio
copiare i files
uno per uno, conservandone attributi e ACL, credo che sia necessario
(attendo
e spero in smentite) usare anche li` un filesystem dello stesso tipo
di quello della
macchina d'origine e cioe`, nel caso di quelle Windows NTFS.
Mi potro` fidare a gestire delle partizioni NTFS su una macchina
Linux?
Anche perche' sulla stessa dovro` gestire partizioni ext3 di macchine
Linux, che
e` possibile far gestire da Windows con Ext2Fsd; ma sinceramente non
so cosa
sia peggio o cosa sia meglio.
Boh? Mah? Forse ...
Grazie e ciao
Andrea

 destinazione e backup.
Ogni tecnica hai suoi pro ed i suoi contro. Se ti serve il versioning
dei file, allora dovresti mettere in mezzo sistemi come git e/o
mercurial, mentre se ti serve anche un backup incrementale dovresti
usare strumenti come dar e rsync. di sicuro Bacula ti risolve tutti
questi problemi in una volta sola, ma, come ho gia` detto, personalmente
l'ho trovato macchinoso. Inoltre, come ho gia` detto, per i miei scopi
Tar va piu` che bene[1] :)
Enrico
[1] o quasi, non puoi immaginare la mia felicita` nello scoprire che il
Tar di Debian era compilato senza il supporto alle ACL (per fortuna che
e` rimpiazzabile con il pacchetto bsdtar)

 avviso ma va...
Appunto, e` troppo macchinoso per i miei scopi. Per la cronaca, un
backup full dei dati da preservare (e solo di quelli), da me occupa meno
di 50Gb (una LTO2 conta 200/400Gb)
Enrico

 piccola mandria di server con installazioni andate a male; 
Su 2003, sfruttando il sistema delle shadow copy, funziona benone, 
addirittura consente di ritirare su una macchina da zero (pure io ero 
molto diffidente a riguardo).
Noi comunque usiamo HP dataprotector su unix, sia perché è centralizzato 
(e quando fai il backup di 300 macchine tra win e unix _serve_ che sia 
centralizzato), sia perché gestisce backup Oracle, Domino, DB2, SQL, 
SAP, zero downtime backup su doppia san, nonché backup a livello 
filesystem o virtual disk delle macchine in ambiente VmWare ESX, sia 
perché una delle cose che ntbackup non fa è gestire un DB con versioni 
dei file backuppati. E quando devi spulciare quale degli nmila file 
backuppati vuoi recuperare (1TB di file server e 2500 utOnti...), la 
cosa è indispensabile...
-- 
GenTLe ...di Varese, provincia.
La mia HP: 
http://digilander.iol.it/thegentle/index.htm
La vita è fatta anche di ardue scelte, tipo: "Un cuba... O una birra 
media???"

 Tar va piu` che bene[1] :)
Se voglio prima fare il backup su disco file a file con le loro ACL
di diversi filesystem (NTFS ed ext3) e poi salvare su LTO, allora non
mi basta Bacula, almeno per la prima fase (backup su disco file a file).
Ho visto che rsync o cwRsync + robocopy possono risolvere questo 
problema per NTFS, nel senso che con rsync copio i files, con 
trasferimento incrementale ottimizzato ogni volta successiva alla prima 
mentre con robocopy posso copiare solo attributi, permessi e ACL dei
files e delle directory. Questo comunque comporta che sulla macchina
di backup ci siano filesystem NTFS, anche se sotto Linux; mentre per le 
macchine Linux posso andare di rsync liscio su filesystem ext3.
Infine Bacula gestira` il backup su tape di tutto questo ben di Dio.
Credo che tutto cio` dovra` essere testato ben benino, sia per 
verificare le prestazioni, sia per verificare che tutto funzioni come 
dovrebbe, ripristini compresi.
Il versioning sarebbe ancora piu` carino, ma la configurazione 
diventerebbe vieppiu` complessa e quindi per ora lascerei perdere.
Andrea

 Linux?
Personalmente lascerei perdere, ad ognuno il suo mestiere.
Piuttosto mille volte meglio usare prodotti come Bacula o Amanda con 
agenti nativi per i vari s.o.
Oppure un software commerciale meno "blasonato" (quindi piu' economico) 
ma comunque funzionale come NovaNET oppure Retrospect.
-- 
Bye
Gianfranco Bartolini
(gianfranco punto bartolini at tiscali punto it)

 (e quando fai il backup di 300 macchine tra win e unix _serve_ che sia 
Perfettamente d'accordo


 da zero della macchina? ;-)
Su 2000 mai provato, ma su NT col cavolo che avevi una macchina 
funzionante se cercavi di tirarla su da un backup :-)
Si faceva molto prima a rifarla e poi recuperare i file singoli dal nastro .


Gianfranco Bartolini ha scritto:
 > twistedbrain ha scritto:
 >
 >> problemi, rimane comunque quello che preferirei avere i files uno a
 >> uno disponibili
 >> sulla macchina di backup.
 >
 > Per questo puoi usare tool anche gratuiti come syncback per tenere
Grazie per il riferimento, sembra interessante.
 > mirrorate le dir dei dati utente che successivamente andrai a salvare su
 > nastro, pero' questo non e' un backup completo della VM. In caso di
 > problemi dovrai ripristinarla in altri modi, es. con il restore da uno
 > snapshot.
Si`. All'inizio l'avevo detto. Faccio fatica a seguirmi io da me 
medesimo, capisco che non sia facile. Snapshot o backup delle immagini
delle maccchine virtuali intendo farli incrociati nottetempo fra i due
server Xen che hanno abbondante spazio a disposizione e poi, una volta a 
settimana, quando non faccio l'altro tipo di backup perche' sarebbe
inutile, essendo gli utenti che possono modificare i dati a casa,
mi faccio una copia di queste immaggini sul server di backup e poi su 
LTO. Tanto i dischi SATA da 1 TB, adesso te li tirano dietro e in tutto
avro` un 350 GB da salvare in un full.
 >> Rimane il problema della copia su NAS, nel senso che se ci voglio
 >> copiare i files
 >> uno per uno, conservandone attributi e ACL, credo che sia necessario
 >> (attendo
 >> e spero in smentite) usare anche li` un filesystem dello stesso tipo
 >> di quello della
 >> macchina d'origine e cioe`, nel caso di quelle Windows NTFS.
 >
 > E' per questo che ti dicevo di usare gli strumenti nativi, gestiscono le
 > acl e salvano in un file compresso che poi manipoli come vuoi,
 > esattamente come faresti con tar/gzip
Si`, ma c'e` sempre il problema all'atto del recovery di non poterlo
fare in modo immediato, ovvero devi sempre passare attraverso un altro
programma (coi suoi modi e i suoi tempi) e poi cercare dentro a una
palla di bytes quelli che ti interessano da ripristinare.
 >> Mi potro` fidare a gestire delle partizioni NTFS su una macchina
 >> Linux?
 >
 > Personalmente lascerei perdere, ad ognuno il suo mestiere.
Sul sito di ntfs-ng3 dicono che e` assolutamente stabile e affidabile.
Speriamo bene (nell'ultima stabile di aprile hanno corretto dei
bachi piuttosto agghiaccianti).
 > Piuttosto mille volte meglio usare prodotti come Bacula o Amanda con
 > agenti nativi per i vari s.o.
Si`, questo e` vero, ma di nuovo ti aumentano i tempi di ripristino;
vai a trovare dove sono salvati, magari fai un ripristino di una
parte di un full e poi di una parte di un differenziale: e` una cosa che 
ti puo` richiedere alcune decine di minuti, mentre se hai i files li` su 
un filesystem con tutti i permessi, le ACL e gli attributi a posto ti 
basta una copia in rete.
Comunque come strategia generale quella che indichi potrebbe essere piu` 
robusta, ma anche quella che ipotizzo, se sufficientemente testata ed 
automatizzata, potrebbe esssere abbastanza affidabile.
In ogni caso pero` anche la copia su filesystem deve essere fatta 
versionando, altrimenti puoi recuperare in modo immediato solo l'ultimo
giorno, diversamente per il recupero di giorni precedenti all'ultimo 
devi ricorrere ai backup su LTO con il solito balletto di ricerche e 
ripristini.
Ho visto che probabilmente rdiff-backup potrebbe fare al caso o 
altrimenti uno script rsync (di Tridge, come esempio sul sito di rsync).
Bene, ora mi basta mettere insieme tutto cio`, ma prima vado a dormire.
Andrea

 mi basta Bacula, almeno per la prima fase (backup su disco file a file).
Questo non lo sapevo anche perche`, come ho detto, all'epoca scartai
Bacula per la gestione dei miei backup. Inoltre, essendo il mio file
server implementato con Samba, non ho mai avuto problemi relativi ad ACL
e similari se non sotto Linux (problemi risolti con le apposite opzioni
di Tar, terrei a ricordare). Comunque, per il backup di Windows, allo
stato attuale delle cose, penso che l'unico strumento gratuito che non
richieda troppi sbattimenti sia il programma integrato per la gestione
dei backup, in quanto permette la creazione di archivi contenenti
tutte le informazioni relative ai file. L'unico dubbio che ho riguarda
la portabilita` dell'archivio, ovvero se e` possibile leggere un backup
effettuato con gli strumenti presenti in Windows 2000 su Windows 2003
(giusto per fare un esempio)
Enrico

 (giusto per fare un esempio)
Per rispondere a questo esempio credo di si`.
Ed e` tutto vero, rimane il fatto che se riesco ad ottenere una copia
su
disco granulare a livello di singolo file versionata e conservante
tutti gli attributi
e le ACL del sistema di origine, preferisco e sembra, previa prove,
che con
strumenti come rdiff-backup (o rsync) e robocopy sia possibile
riuscirci.
Grazie e ciao,
Andrea