PLD, please review. We also need the backup to secondary to be optional/on demand for our latest implementation plans.
*Will Stevens* Chief Technology Officer c 514.826.0190 <https://goo.gl/NYZ8KK> On Thu, May 17, 2018 at 3:22 PM Suresh Kumar Anaparti < sureshkumar.anapa...@gmail.com> wrote: > Hi Si, > > No. not possible to disable the backup to secondary. It copies the volume > snapshot to secondary in a background thread using asyncBackup param (set > to true) and allows other operations during that time. > > I understand that the backup was on demand when any operations are > performed on the snapshot. But, backup during that time may take > considerable time (depending on the snapshot size and the network > bandwidth), which can result in the job timeout and the User may assume > that it is already Backed up based on its state, unless it is documented. > > -Suresh > > On Fri, May 18, 2018 at 12:23 AM, Simon Weller <swel...@ena.com.invalid> > wrote: > > > Suresh, > > > > > > With this new merged PR, is it possible to disable the backup to > > secondary completely? I can't tell from the reference spec and we're not > on > > a 4.10/4.11 base yet. > > > > For the record, in the instances where a volume or template from snapshot > > was required, the backup image was copied on demand to secondary. > > > > In an ideal world, secondary storage wouldn't even be involved in most of > > these options, instead using the native clone features of the underlying > > storage. > > > > > > - Si > > > > ________________________________ > > From: Suresh Kumar Anaparti <sureshkumar.anapa...@gmail.com> > > Sent: Thursday, May 17, 2018 1:37 PM > > To: dev@cloudstack.apache.org > > Cc: Nathan Johnson > > Subject: Re: Snapshots only on Primary Storage feature > > > > Hi Glen / Si, > > > > In PR# 1697, the global setting *snapshot.backup.rightafter* if set to > > true, it'll be the default behaviour and snapshot is copied to the > > secondary storage. If set to false, then the snapshot state transitions > are > > mocked and Snapshot would be in BackedUp state even though it is not > really > > in Secondary storage, which doesn't make sense. Also, that will enable to > > create a volume or template from the snapshot, which will obviously fail. > > > > This behavior was changed with the PR > > https://github.com/apache/cloudstack/pull/2081. There is a clear > > separation > > of create and backup volume snapshot operations. The global setting > > *snapshot.backup.rightafter* has been removed in PR# 2081. > > > > -Suresh > > > > On Thu, May 17, 2018 at 8:40 PM, Simon Weller <swel...@ena.com.invalid> > > wrote: > > > > > Glen, > > > > > > > > > This feature was implemented in 4.9 by my colleague Nathan Johnson. > You > > > enable it by changing the global setting snapshot.backup.rightafter to > > > false. > > > > > > > > > The PR is reference here: > https://github.com/apache/cloudstack/pull/1697 > > > > > > > > > We have the exact same use case as you, as we also use Ceph. > > > > > > > > > - Si > > > > > > > > > ________________________________ > > > From: Glen Baars <g...@onsitecomputers.com.au> > > > Sent: Thursday, May 17, 2018 9:46 AM > > > To: dev@cloudstack.apache.org > > > Subject: Snapshots only on Primary Storage feature > > > > > > > > > Hello Devs, > > > > > > > > > > > > I have been thinking about a feature request and want to see what > people > > > think about the use case. > > > > > > > > > > > > We use KVM + Ceph RBD as storage. > > > > > > > > > > > > Currently, when a client takes a snapshot, Cloudstack takes a Ceph > > > snapshot and then uses qemu-img to export to secondary storage. This > > > creates a full backup of the server. Clients want to use this as a > daily > > > snapshot and it isn’t feasible due to the space requirements. > > > > > > > > > > > > We would like create the snapshot only on primary storage. It is > > > replicated offsite and fault tolerant. I can see that the download > > snapshot > > > and create template features may be an issue. > > > > > > > > > > > > I have seen the below features in the recent releases and wondered if > > this > > > was the direction that the development was going. > > > > > > Separation of volume snapshot creation on primary storage and backing > > > operation on secondary storage. > > > > > > Bypass secondary storage template copy/transfer for KVM. > > > > > > Kind regards, > > > > > > Glen Baars > > > > > > BackOnline Manager > > > > > > > > > > > > T 1300 733 328 / +61 8 6102 3276 > > > > > > NZ +64 9280 3561 > > > > > > > > > > > > www.timg.com<http://www.timg.com/> > > > > > > [http://images.dbonline.com.au/images/fb.png] Facebook< > > > https://www.facebook.com/TheInformationManagementGroup> [ > > > http://images.dbonline.com.au/images/li.png] LinkedIn< > > http://www.linkedin. > > > com/company/the-information-management-group?trk=hb_tab_ > > compy_id_2724246> > > > > > > > > > > > > Watch a short video about what we do!<https://www.youtube.com/ > > > watch?v=scLGLwSIFQc> > > > > > > [http://images.dbonline.com.au/images/timgv3.jpg]< > https://goo.gl/eAHLO7> > > > > > > This e-mail may contain confidential and/or privileged information.If > you > > > are not the intended recipient (or have received this e-mail in error) > > > please notify the sender immediately and destroy this e-mail. Any > > > unauthorized copying, disclosure or distribution of the material in > this > > > e-mail is strictly forbidden. > > > > > > > > > > > > This e-mail is intended solely for the benefit of the addressee(s) and > > any > > > other named recipient. It is confidential and may contain legally > > > privileged or confidential information. If you are not the recipient, > any > > > use, distribution, disclosure or copying of this e-mail is prohibited. > > The > > > confidentiality and legal privilege attached to this communication is > not > > > waived or lost by reason of the mistaken transmission or delivery to > you. > > > If you have received this e-mail in error, please notify us > immediately. > > > > > >
