Below is just my assumption: Storage hardware should make sure no data lost, the solution in this layer may be easy but expensive in CloudStack's perspective. CloudStack provides schedule snapshot[1] is just for your convenience, with backuped DB, you can easily restore the whole cloud. But hardware failure may still cause some data lose in 2 scheduled snapshots or even corruptted for incremental snapshot. The progress of Take snapshot and restore to VM is also time consumption.
Using DFS(eg: ceph) as primary/secondary storage is similiar, the DFS itself needs to keep data intact. And currently it's not fully supported. [1] snapshot in cloudstack is volume backup rather than vm snapshot at this moment. On Tue, Oct 23, 2012 at 2:22 PM, Paco Orozco <paco.oro...@upcnet.es> wrote: > Hi Julien, > > Good point! We have a private IaaS cloud and we have the same question. > At the beginning documentation and forums recommends to backup MySQL DB > and the secondary storage. > > I'm using Cloudstack and Xen servers with LVM as a primary storage. > > I'm doing it but I've got some not solved questions. > > 1) Geoff says "You should have every VM running a Scheduled Snapshot > routine, that way if you have a disaster, you can recreate your > architecture, and restore VMs from Snapshots / Templates". When you > schedule this snapshot routine it will create snaps on secondary > storage. Does this snaps count as a consumed resources for users? Must > they will pay for it? Can users delete them? > > 2) I'm now testing a solution for PHD in order to do VM backups from Xen > Server. Are you using Xen or KVM/VMware? > > 3) I need to protect myself from harware failures (mirroring) and > software or human errors (backup). Are you only using mirror? > > Thanks > -- > Paco Orozco (paco.oro...@upcnet.es) > SIP: paco.oro...@upcnet.es > Backoffice. Àrea de Serveis TIC > UPCNet > Edifici Vértex - Pl. Eusebi Güell, 6 > Teléfon centraleta: 93.40.11600 > GPG Key ID: 0x3EDEC0AC > -- Gavin
