cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julien Garet <julien.ga...@inria.fr>
Subject Re: backup a cloudstack deployment
Date Thu, 25 Oct 2012 12:06:52 GMT


De: "Paco Orozco" <paco.orozco@upcnet.es> 
À: cloudstack-users@incubator.apache.org 
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 (paco.orozco@upcnet.es) 
SIP: paco.orozco@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 


</blockquote>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message