cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <>
Subject Re: snapshot vs backup
Date Thu, 08 Nov 2012 17:47:15 GMT
Alright, I do remember that thread. I was just considering upgrading some
of the ways CLVM handles snapshots/backups and wanted to do it in a way
that was consistent with the way we're doing VHD or QCOW2 going forward,
but it sounds like there's probably not much I can do now without having to
rework it again when the storage refactor happens to see what that looks

On Thu, Nov 8, 2012 at 10:41 AM, Clayton Weise <> wrote:

> >Imho snapshots should be handled by a plugin. So on a Snapshots aware
> >SAN we should try to use the build in snapshots capabilities of that SAN
> >instead of doing it ourself.
> This can considerably change the way storage is handled with XenServer and
> iSCSI/FC since right now one SR is equivalent to a single LUN on your
> storage array but that SR can contain many different volumes for VMs.  In
> order to take advantage of snapshots on the array you would need to create
> a separate SR for each volume (somebody feel free to correct me if I'm
> wrong here) since the array wouldn't know about the individual volumes/LVMs
> inside of the SR.  With NFS it's easier because it's all just files, but
> block storage is different and can vary greatly in behavior from one HV to
> another.
> -----Original Message-----
> From: Wido den Hollander []
> Sent: Thursday, November 8, 2012 3:50 AM
> To:
> Subject: Re: snapshot vs backup
> On 07-11-12 18:13, Marcus Sorensen wrote:
> > I believe I saw this discussed once somewhere, but at the moment
> snapshots
> > are basically backups, correct?  You'll have to forgive my ignorance if I
> > don't understand how it works on all platforms/storage types.
> >
> Edison brought this up with a storage refactor.
> > So moving forward are we renaming everything that's snapshot to backup
> > (since it works great for that as-is) and implementing a new snapshot, or
> > splitting the existing snapshot functionality into taking the actual
> > snapshot vs copying it to secondary storage (backup), or leaving snapshot
> > as-is and implementing some flag or something else that allows for both
> the
> > existing backup functionality as well as an instant cow style backup?
> >
> Imho snapshots should be handled by a plugin. So on a Snapshots aware
> SAN we should try to use the build in snapshots capabilities of that SAN
> instead of doing it ourself.
> Same goes for RBD, QCOW2, etc, etc.
> Backups should be different indeed, still handled differently for
> different storage backends just to prevent we are working against the
> storage backend while it could have awesome features for this.
> In the end a backup should end up at the Secondary Storage.
> Still, this is something that needs to go into the Storage Layer
> refactor and we need to have this written down.
> This thread covers a lot of it: "Requirements of Storage Orchestration"
> from over a week ago.
> Wido

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