incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
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
like.


On Thu, Nov 8, 2012 at 10:41 AM, Clayton Weise <cweise@iswest.net> 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 [mailto:wido@widodh.nl]
> Sent: Thursday, November 8, 2012 3:50 AM
> To: cloudstack-dev@incubator.apache.org
> 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
>

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