Hi Mike,

     The timestamp comes handy when the source and destination filer are across timezones and you wish to schedule

your dataset backup in a particular timezone.

For example my dataset is in GMT but my filers are in IST so my dataset backup schedules are run on

GMT.

C:\>dfpm dataset list -x 5221
Id:                              5221
Name:                            Cust
Policy:                          Back up, then mirror
Description:                     Testing for burt+cust
Owner:                           Adaikkappan
Contact:                         adaikkap@netapp.com
Volume Qtree Name Prefix:        Timestamp
DR Capable:                      No
Requires Non Disruptive Restore: No

Node details:

   Node Name:              Primary data
   Resource Pools:         Primary_RP
   Provisioning Policy:    pri_pol
   Time Zone:              GMT
   DR Capable:             No
   vFiler:
   Export Protocol:        mixed
   NFS Protocol Version:   v3
   Disable setuid:         1
   Anonymous Access UID:   0
   Read-only Hosts:        None
   Read-write Hosts:       All
   Root-access Hosts:      None
   Security Flavors:       sys
   CIFS Domain:            BTCLAB
   CIFS Share Permissions: Everyone:full_control

   Node Name:           Backup
   Resource Pools:      Backup_RP
   Provisioning Policy: sec_pol
   Time Zone:
   DR Capable:          No
   vFiler:

   Node Name:           Mirror
   Resource Pools:      Mrr_RP
   Provisioning Policy:
   Time Zone:
   DR Capable:          No
   vFiler:

C:\>

lnx186-149:/ # snap list Timestamp
Volume Timestamp
working...

  %/used       %/total  date          name
----------  ----------  ------------  --------
13% (13%)    0% ( 0%)  Jul 08 20:56  dfpm_base(Cust.5221)conn1.0 (snapvault,acs)
28% (19%)    0% ( 0%)  Jul 08 20:56  2009-07-08 15:28:54 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< timestamp
42% (25%)    0% ( 0%)  Jul 08 20:51  dfpm_base(Cust.5221)conn1.1 (snapvault)
49% (19%)    0% ( 0%)  Jul 08 20:51  2009-07-08 15:23:59 weekly_f3050-184-38_Timestamp.-.qt_cust<<<<<<<<<<<<<<<<<<<<<<<<times are different.
71% (60%)    0% ( 0%)  Jul 08 20:40  dfpm_base(Cust.5221)conn1.2
72% (12%)    0% ( 0%)  Jul 08 20:40  2009-07-08 15:13:06 monthly_f3050-184-38_Timestamp.-.qt_cust
lnx186-149:/ #

If you see in the above output the weekly snapshot timestamp is different from the date output of the file.

49% (19%)    0% ( 0%)  Jul 08 20:51  2009-07-08 15:23:59 weekly_f3050-184-38_Timestamp.-.qt_cust

But unfortunately the timestamps cant be turned off like the other options.

28% (19%)    0% ( 0%)  Jul 08 20:56  2009-07-08 15:28:54

The snaphost and volume naming can be controlled by the below options.

C:\>dfm options list | grep -i pmcus
pmCustomNameUseHostName               No
pmCustomNameUsePrefix                 Yes
pmCustomNameUseQtreeList              No
pmCustomNameUseRetentionType          No
pmCustomNameUseType                   No
pmCustomNameUseVolumeName             No

C:\>

In this case the snaphost will only have the timestamp( ie it cant be turned off)

Regards

adai

Hi Mike --

Yes, you could, but in your example, none of the timestamps actually match.  And, depending on your situation, you might not be able to run "snap list", you might only have the snapshot names (e.g. if you just navigate into the .snapshot directory).  We get many customers who want to sort out what a given volume, qtree or snapshot represents based on nothing but the name, so embedding a timestamp is useful.

We could consider adding an option to use an index instead of a timestamp, but there are uniqueness issues.  We could code around those if we needed to.

-- Pete

I'm finally getting back to this one.

When I browse a CIFS share from Windows XP, I see the full snapshot names.  This happens both from Windows Explorer and a DOS prompt.  Did you do anything special to make your systems show only the 8.3 names?