With Prot Mgr 3.8, the name for the local snapshot copies includes a timestamp. Having a timestamp in the name for the snapshot copies is kind of unwielding. Plus, it is kind of redundant as there is already a "date" column in the output of "snap list". Is there an alternative to the timestamp? In which case, is there a way to remove the timestamp from the snapshot name?
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
C:\>dfpm dataset list -x 5221 Id: 5221 Name: Cust Policy: Back up, then mirror Description: Testing for burt+cust Owner: Adaikkappan Contact: email@example.com Volume Qtree Name Prefix: Timestamp DR Capable: No Requires Non Disruptive Restore: No
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:
lnx186-149:/ # snap list Timestamp Volume Timestamp working...
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
In this case the snaphost will only have the timestamp( ie it cant be turned off)
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.
With regards to the timestamps not matching, my client wondered the same thing. As it turns out, the timestamp on the snapshot names are GMT, even though all of my filers AND all of my datasets are on Central time. As you can see from my earlier post, the date of the snapshot and the timestamp on the snapshot names differs by 5 hours. Perhaps, there is an option that I am missing. But that's another thing that's going to confuse the heck out of the client.
I understand your use case for using the timestamp to sort out the snapshots. However, a common use case is to simply direct the users to the hourly.0 or daily.0 snapshot directory. That is the use case that my particular client is acustom to. And they will have volumes that are backed up outside of protection manager and with the filers' builtin scheduler.
The client pointed out the following issue with the new snapshot names. If you access the CIFS shares in Windows Explorer and go to the ~snapshot directory to perform a user-directed restore, the snapshot names/directories all get truncated:
Hence, the client cannot determine which snapshot to use. Is 2009-0~1 the latest? At least with hourly.0, hourly.1, etc, they know hourly.0 is the latest.
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?
In my case I had a volume on my primary storage on aggr0, I moved this volume (with snapmirror) to aggr1, reconfigured my DFM policy but since, the snapshot folder on a windows client (2003/7/2008) show trunked (8+2) folders names while snapshot list is OK...
In this DFM policy there is also another volume from another filer... All is fine for that one.
I looked everywhere on the secondary and primary filer vol options, vol lang snapshot list...