Snapshot Autodelete vr Snapvault Snapshots

[emanuel]

Hello everyone

Had a discussion with a client on the use case of snapshot autodelete and KB6954 mentions that snapshots are only protected when they are marked as "busy".

however in their case their DFPM_base was not protected at the time and snap autodelete removed it making their backup "broken"; for it to be marked as busy the snapvault update needs to take place to lock the base snapshot.

my question with PM is, when i setup a dataset to be protected and I protect now, this is the baseline operation; the new DFPM_base is created, the data is transfered over to a secondary.  Is this considered the "snapvault update" or is there another step I must do to "lock" the initial DPFM_base?

[radek_kubka]

Hi,

The same KB you are talking about says:

What snapshots is autodelete allowed to delete?

• The user can protect certain kinds of snapshots by deferring their delete.
• The "commitment" option defines this:
      "try": Delete snapshots which are not being used by any data mover, recovery or clones. (NOT LOCKED)
      "disrupt": Delete snapshots locked by data movers - snap mirror, dump/restore . (Mirror, dumps are aborted)
• Snapshots locked by clones, snap restores, cifs shares are not deleted.
• "disrupt" snapshots are only deleted if there are no "try" snapshots left to delete.

Did you / the customer look how the commitment option has been set?

Regards,

Radek

[adaikkap]

When provisioning manager sets up autodelete its does the following settings,

Information:      Change autodelete setting on volume VolToBeProvision:thinlyprov_lun (32): [ commitment=destroy ],[ defer_delete=prefix ],[ delete_order=oldest_first ],[ destroy_list=lun_clone,vol_clone,cifs_share ],[ prefix=dfpm ],[ state=on ],[ target_free_space=5 ],[ trigger=volume ]

Similarly what you can do is setup up defer_delete=prefix and prefix=dfpm for your snapshot autodelte.

Regards

adai

[radek_kubka]

OK, the KB in question doesn't talk about 'commitment=destroy' possibility, but I bet it means literally anything can be wiped without a warning.

Shouldn't the default behaviour of PM be more gentle & use rather 'commitment=try'?

Regards,

Radek

[emanuel]

Good stuff guys ... I will speak with them shortly and get their autodelete settings and compare with their environment.  I do not know if they are doing autodelete via the command line or provisioning manager.

[adaikkap]

Hi Emanuel,

     When you have a SnapVault relationsihp its only the destiniaton snapshot that is busy. Like the one below.

madaan-vsim3> snap list sv_ds_backup
Volume sv_ds_backup
working...

  %/used       %/total  date          name
----------  ----------  ------------  --------
  0% ( 0%)    0% ( 0%)  Sep 13 08:47  madaan-vsim3(987640-32-0)_sv_ds_backup-base.5 (busy,snapvault)
  1% ( 1%)    0% ( 0%)  Sep 13 08:25  2010-09-13 02:42:14 daily_madaan-vsim3_sv_ds_backup.-.sv_ds_madaan-vsim1_sv_ds.test_qt1
madaan-vsim3>

But not on the source.It will look like this, but they are not busy.

madaan-vsim1*> snap list sv_ds_1
Volume sv_ds_1
working...

  %/used       %/total  date          name
----------  ----------  ------------  --------
34% (34%)    0% ( 0%)  Sep 13 09:23  dfpm_base(sv_ds.2160)conn1.0 (snapvault,acs)
48% (29%)    0% ( 0%)  Sep 13 09:23  2010-09-13 03:40:06 daily_madaan-vsim1_sv_ds_1.-.second
57% (29%)    0% ( 0%)  Sep 13 09:13  2010-09-13 03:30:06 hourly_madaan-vsim1_sv_ds_1.-.second
madaan-vsim1*>

Regards

adai

[radek_kubka]

This is fine for all snapshots on the source excluding the base one.

I reckon the baseline wouldn't get deleted with commitment=try (or would it?)

Regards,
Radek

[adaikkap]

Hi

     Below is what the man pages say.

This option determines whether a particular snapshot is allowed to be deleted by autodelete. Setting this option to try permits snapshots which are not locked by data protection utilities (e.g. dump, mirroring, NDMPcopy) and data backing functionalities (e.g. volume and LUN clones) to be deleted. Snapvault snapshots are not locked and thus are not protected from autodelete by the try option. Setting this option to disrupt permits snapshots which are not locked by data backing functionalities to be deleted in addition to those which the try option allows to be deleted. Setting this option to destroy in conjunction with the destroy_list option allows autodelete of snapshots that are locked by data backing functionalities (e.g. LUN clone). Since the values for the commitment option are hierarchical, setting it to destroy will allow destruction of the snapshots which the try and disrupt options allow to be deleted.

Regards

adai