>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:w...@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
