penso che Francesco stesse sottolineando che il backup diciamo "anti utente che si cancella i file" viene gratuitamente con un fileserver netapp, anche in cifs, addirittura in modo che puo' essere gestito autonomamente dall'utente stesso.
Con questa tecnologia si possono risparmiare ore di lavoro dell'IT per recuperare file da nastri, consentendo all'utente di ripescarsi in pochi secondi il file cancellato/modificato dalla cartella .shapshot.
Una cosa di cui sicuramente il sistemista si innamora perche' gli toglie una rottura notevole 
Poi sempre come diceva Francesco, ci sono tutte le possibilita' di replicare i dati su altra macchina (cluster, metrocuster, snapmirror) sia di portare tutto su nastro "via NDMP".
Magari stiamo chiamando la stessa cosa in due modi diversi
sì: quello che tu chiami "backup" francesco lo chiamava "disaster recovery" 
Tinto1970 ha scritto:
Magari stiamo chiamando la stessa cosa in due modi diversi
sì: quello che tu chiami "backup" francesco lo chiamava "disaster recovery"
Lo chiamo disaster recovery nel caso del NetApp.
Per il fatto che tramite NDMP salvi l'intero volume e non la singola share/file documento ecc. e per il fatto che con questo puoi recuperare l'intero storage oltre che il singolo file. Spero di esser stato più chiaro questa volta
Ciao,
sperando che non ce ne voglia l'OP, dato che stiamo andando piu' verso questioni "quasi filosofiche".
Premessa: conosco NetApp solo a livello teorico.
Credo che tutto l'oggetto del contendere sia sulla definizione di backup e sul livello della propria "sana" paranoia (e sul fatto che anche in letteratura devo dire che ogni tanto si mescolano un po' le terminologie).
Personalmente preferisco avere i backup fuori dallo storage che li contiene, qualunque esso sia (EMC, NetApp, HP, quellochevolete) per il semplice motivo che avere una copia di sicurezza sullo stesso oggetto che devo proteggere mi sembra un cane che si morde la coda: se perdo l'oggetto protetto perdo anche il suo backup. E, opinione personale, non esiste l'oggetto indistruttibile capace di resistere a tutto e tutti (mai sottovalutare cosa possono fare gli utenti, anche sistemisti )
Ovviamente questo ragionamento vale per i backup "importanti" (daily, weekly): per i backup "spendibili e frequenti" per i danni passeggeri (l'utente che elimina quello che non dovrebbe o simili) mi va benissimo uno snapshot dello storage, ancora meglio se posso poi gestirli con facilita'. (nota: snapshot a livello storage, non di VM).
Per quanto riguarda copia di backup esterna e DR, io considero che una copia esterna diventi un copia di DR solo quando viene portata "in un posto sicuro" (replica a distanza chilometrica/in altro edificio, tape portati in banca/in altra sede e cosi' via) e ha associato un piano che indica quando e come va usata.
Il tutto ovviamente IHMO.
--
Giuseppe
L'argomento backup, restore, business continuity, disaster recovery, è un argomento che porta sempre a dei bei confronti e discussioni.
Fossimo davanti a birre e sprite (Giuseppe ) a quest'ora avremmo trovato un punto d'accordo.
prima di tutto dovresti dirci quale DB usi ma suppongo oracle, visto anche lo storage che hai dietro.
Probabilmente stiamo parlando di db molto carichi e/o che devono essere molto performanti e solidi.
Penso comunque che la tua architettura sia davvero un po' troppo complessa, nel senso che usare così pesantemente RDM è "filosoficamente" contrario alla virtualizzazione, nel senso che come dici tu gestire dei vmdk è molto più facile.
Anche il creare un datastore per ogni vmdk è probabilmente non giustificato neanche in un ambiente super prestante. Sicuramente non converrà mettere tutti i vmdk in un solo datastore, ma arrivare a un buon compromesso, analizzando se ci sono colli di bottiglia da qualche parte.
E' vero il discorso che fai sul fatto che gli snapshot che fai con navisphere, nella situazione RDM, ti permettono di lavorare a livello di device mentre gli shansphot fatti da ESXi lavorano a livello di VM. Ci sono pregi e difetti in entrambi i casi, che dipendono molto dagli applicativi che sono nella vm, in questo caso il db.
Io ho un po' di esperienza con MySQL: in quel caso ciò che ho visto essere importante per le prestazioni non è tanto "come vanno i dischi" ma "quanto più possibile uso lra RAM invece di fare IO su disco".
Ciao,
devo dire che sia Tinto che Luca ti hanno fornito ottimi spunti di riflessione.
A questo punto, se puoi, potresti mettere in piedi qualche VM di test e fare delle prove.
E' probababile che la tua configurazione attuale sia stata fatta per mirare alle performance.
Se i vari RDM e relative lun, sono distribuite su controller diversi e VDISK diversi (non so come li chiama EMC), con raid level diversi, avrai un carico sullo storage ottimizzato.
Ripeto, metti in piedi un ambiente di test e prova
Ciao
Grazie a tutti per la condivisione di idee.
I DB utilizzati , i quali reggono il Business Aziendale sono Oracle e Adabas.
Sicuramente ho tralasciato molti aspetti , nel chiedere un vostro parere
riguardo performance tra vmdk e rdm.
Alcuni di questi aspetti sono;
L' utilizzo di rdm ci facilita molto la gestione del Disaster Recovery, ovvero;
Prendendo per esempio i 6 dischi, tramite MirrorView, vengono replicati,
in modalita asincrona ( ogni 5 minuti ) verso il sito di DR, con conseguente
clone, in un determinato momento della giornata, per preservare consistenza e
non avere problemi in caso di replica di un errore sul DB nell' arco di 5 minuti.
Mirror attivo H24, al termine del batch serale, stop del DB, sincronizzazione forzata sul sito di dr,
golden copy su ulteriori dischi, se tutto ok, restart DB e tutti felici e contenti.
Questo se fosse gestito con VMDK mi porterebbe sicuramente ad utilizzare piu spazio disco,
se avessi i vmdk su due DataStore diversi, sicuramente avrei la necessita non di due lun da 150 GB,
ma almeno 150 GB +20%.
Il mio sito DR , e' configurato per ospitare solo le VM Business CORE e quindi anche un +20%
di disco utilizzato non mi darebbe la possibilita di replicare tutto.
Si e' vero, se VMDK ,potrei espandere i dischi a caldo, ma anche tramite Host Level Mirror,
non avrei nessun tipo di disservizio.
Oltre a tutto cio espresso prima e' pur vero che ogni notte, nel nostro ambiente di Prod,
avvengono delle Snap dei 6 dischi ( sempre per prendere in considerazione l' argomento di partenza) ,
le quali ( tramite processo automatico ) vengono montate su di una ulteriore VM per eseguire
report di statistiche, senza intaccare le performance della VM di Prod.
Questo utilizzando Snapshot delle LUN tramite Utility Storage.
E' vero che la domanda fatta in precedenza era stata molto generica e ogni architettura
vive in base a determinate esigenze, ma proprio perche sento sempre molto + parlare di vmdk che di RDM,
che cerco di capire cosa mi possa dare piu performance o valore aggiunto da permettermi di scegliere una piuttosto che l' altra conf.
Grazie ancora Luca e Tinto per le vostre considerazioni e
sono qui ad attenderne altre, ma non bocciatemi tutta l' architettura, altrimenti
mi metto a piangere 
.
Saluti e spero che tali info siano utili anche ad altri utenti.
Sicuramente non ti boccio nulla anche perché oracle so appena come si scrive
una cosa da tenere in conto è anche il "fattore umano": se voi siete "skillati" ed esperti nel lavorare con gli strumenti forniti dal vostro storage ci sono buoni motivi per continuare a lavorare sul quel livello.
In generale gli snapshot fatti dal sistema di storage sono molto veloci ed efficienti. Quelli fatti dall'hypervisor sono più lenti e pesanti ma secondo me più facili da capire e usare: fare un revert è semplice e riporta la VM allo "status quo". Lavorare con gli snapshot a livello di RDM comporta il conoscere bene oltre allo storage anche il sistema operativo e l'applicativo, pena il ritrovarsi con un db che non riparte o con dati incoerenti.