De: "Paco Orozco" <[email protected]> À: [email protected] Envoyé: Jeudi 25 Octobre 2012 11:19:54 Objet: Re: backup a cloudstack deployment
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. The problem when using snapshots from the domain admin, is that, if you set them up within cloudstack, users can't set another schedule policy, say you put a daily schedule for that, your customers won't be able to put another daily snapshot, so you remove a feature. Perhaps you can schedule a batch with the api to snapshot manually all the VMs, but you can't be sure people are not doing a snapshot at the same time which will lead to the second snapshot not working... But your problem is a real one, and errors from operators can always occur. After thinking about it, I guess I will do snapshots at the array level, which I think can also be done with lvm but I don't know how easy it is to schedule and recover from it. A problem still remains, how can one prevent from general hardware failure of the raid array of primary storage ? We just hope it won't happen ? <blockquote> 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 </blockquote>
