Hello Daniel,

We have the same environment, and the same problem.
I agree, the volume snapshots are a pain in time needings. Volume snapshot
does a full copy of the volume through the network from primary storage to
the secondary. May be there is a storage configuration that could optimize
this action, but we have iSCSI for primary storage and NFS por secondary...
For some big volumes it takes up to 8 h to complete the snap.

This is NOT a sustainable solution.

Our customers uses backup agents of their backup solutions, and we (as
providers) have a backup at VMware level (you can find many solutions like
vRanger, veeam, ...), is the only way that we have found to have a
disaster-recovery backup of the platform. We are working now on how to
offer to customers using this backup as a service, facing to have a
global-unique backup solution (and scalable) for all the platform and users.

In this way, for example Veeam backup offers many options to allow users to
recover their own data (configuring access via API), but the problem here
is that in Cloudstack you can't recover a virtual machine on the
virtualization layer without informing the cloud-manager...


Perhaps someone else could light us.




Regards.





Atentamente,
Sebastián Gómez

On Wed, Feb 7, 2018 at 3:35 PM, <daniel.herrm...@zv.fraunhofer.de> wrote:

> Hi All,
>
> We are using CS 4.7.1 with VMWare Hypervisor and advanced networking in a
> private cloud environment. Currently, most of our (internal) customers
> hosting internal services within this environment are using volume
> snapshots to facilitate backups of their virtual machines. Besides the
> obvious downsides of this approach (consistent snapshots of multiple
> volumes, …) we encounter serious problems using this features. In ~10% of
> the cases, snapshots get stuck in the BackingUp state, which sometimes
> causes the whole snapshot queue to stale. In some other cases, recurring
> snapshots are correctly configured, but CS does not try even try to create
> this snapshot, there is no entry in the database.
>
> In summary, we are currently evaluating different options, hence my
> questions here:
>
>
>   *   Are we the only ones encountering that massive problems with volume
> snapshots? Or is this a known problem? Anything we could look at or a hint
> where we could start troubleshooting?
>   *   How are you actually providing backup services to the customer? Are
> there other solutions or products that integrate with CS?
>
> When using another option than the volume snapshots in CS, the most
> important factor would be to keep the ability for the customer to configure
> everything in self-service.
>
> Thanks and regards
> Daniel
>

Reply via email to