Hello, I comment between lines.
On 25/10/12 00:22, Julien Garet wrote: > [...] >> 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? > As far as I know, a snapshot is a resource as others, it has its own limits, > different from the volumes. Users can delete their own snapshots. The service > offer we are planning to provide is to tell users they have all the tools to > plan their own backup (via the snapshots) and are responsible to set it up > for their VMs. We ensure that in case of disaster on primary storage, they > will have tools to recover failed VMs. Yes, but I understand you were looking a way to make a backup for your IaaS Cloud Service. I'm worried that by system admin error can lose all data on primary storage. So I'd like to have a recovery point. I've been thinking in do scheduled snaps of users VMs, in order to be able to recover them in case of disaster. But this way has two problems: Firstly, these snapshots consumes user resources, so I must give one or two snapshots free. This isn't a problem after all. Secondly, user should be able to delete this snaps. So I can assure I will be able to recover all cloud in case of disaster. Imagine one of your admins is installing a patch or upgrading one of my XenServers and it executes a wrong command that deletes all primary storage data. It would be difficult to explain to my customers that i can't recover its VMs. Customers are responsible for do its own backup task. But I need to assure some point of recovery. I hope you can understand my point of view (English, as you has note, is not my native language :-) > [...] > Does anyone face this kind of snapshots problems ? Yes, I've got the same. The fail a lot, and sometimes they are very slow. Thanks -- Paco Orozco ([email protected]) SIP: [email protected] Backoffice. Àrea de Serveis TIC UPCNet Edifici Vértex - Pl. Eusebi Güell, 6 Teléfon centraleta: 93.40.11600 GPG Key ID: 0x3EDEC0AC
signature.asc
Description: OpenPGP digital signature
