Description

This article explores the interoperability between EV and Veritas Access and how the Retention is applied to saveset items created in a Vault Store Partition using Veritas Access with WORM function.

Note: Whilst support for Veritas Access started with EV 11, a public article describes the required steps to enable the option in the VAC. See related articles below.
With EV 12.2, the Veritas Access storage is shown in the VAC, however, in order to display the WORM option, when creating the new Vault Store Partition, the relevant xml configuration file needs to be manually replaced on the EV servers. In newer versions after 12.2, this option will be automatically displayed in the VAC.


Normal use / administration - Relevant steps:

Assuming the configuration of the Veritas Access storage partition was created with the WORM option, and some content was archived based on the relevant target Policy and Retention, the items in the VS partition (savesets) would each have been created with the command to set the retention on the fly according to what's defined in the Policy.

Compared to the WORM function on a NetApp WORM device, where the retention is implemented at the file system level and automatically applied to every file written, with Veritas Access, the retention is set at the moment the file is written / created.

So, with the new items created in the VS partition, following ingestion from the Storage Queue, every item is created with the command to set the retention. This allows the retention to be set based on the active Retention used in the Policy.
If a Policy is later modified to change the Retention, the new archiving will create new savesets with the new retention, accordingly.  

When the Veritas Access cluster is created, a dedicated Console IP is allocated and the recommendation is to use this Console IP for general administration tasks. When using this Console IP the administrator can login directly using the master account.
Alternatively the cluster can be managed  via a node login. From the Access node, which controls the storage disks in the cluster (Active node), load the Access clish (Command line shell) by logging on with su - master.
When logging on to one of the nodes, if that node is not the active node, when using the su - master command, a message is returned as follows: "This account is currently not available".
Logon to the other node and re-entering the su - master command would load the clish correctly.
 

The command to verify the retention on a per file basis is as follows:

Example:
login as: root
root@10.51.23.218's password:
Last login: Fri Sep  1 11:55:20 2017 from access73_01
[root@access73_02 ~]#
[root@access73_02 ~]# su - master
------------------------------------------------------------------------
|                        Veritas Access 7.3.0.0                        |
|                                                                      |
|                          Enterprise Edition                          |
|                   Warning: Authorized Access Only                    |
------------------------------------------------------------------------
Veritas Access 7.3.0.0 (Wed Jul 26 16:14:07 2017), Installed on Thu Aug 31 12:10:00 PDT 2017
Welcome, master (Master). Today's date is Fri Sep 8 02:07:29 PDT 2017
URL for accessing the GUI: https://192.168.13.40:14161/
access73>
To list the existing file systems use   storage fs list

access73> storage fs list
FS                        STATUS       SIZE    LAYOUT                    MIRRORS
   COLUMNS   USE%  NFS SHARED  CIFS SHARED  FTP SHARED  SECONDARY TIER
========================= ======       ====    =======================   =======
   =======   ====  ==========  ===========  ==========  ==============
ev_vs_partition           online     50.00G    simple                    -
   -           2%     no         yes           no           no
ev_worm_fs                online     35.00G    simple                    -
   -           6%     no         yes           no           no
access73>

To list the CIFS shares use  cifs share show

access73> cifs share show
                ShareName                  FileSystem  ShareOptions
         access_partition             ev_vs_partition  owner=root,group=root,fs_
mode=1777,allow=EVLAB\vaultadmin,rw
        access_worm_share                  ev_worm_fs  owner=root,group=root,fs_
mode=1777,allow=evlab\vaultadmin,rw,full_acl
access73>

Knowing the folder used to define the VS partition, we can build the path to a folder location where savesets were created:

Windows UNC path:
"\\access73.evlab.local\access_worm_share\wormpart1\2017\09-08\5\12E"

Clish storage path:
"/vx/ev_worm_fs/wormpart1"


After locating a sample DVS file name from the above path, from the clish prompt run the command:

storage fs retention show /vx/ev_worm_fs/wormpart1/2017/09-08/5/12E/512E9E5E2E9E2F4B980C7E5A67A01F21.DVS

access73> storage fs retention show /vx/ev_worm_fs/wormpart1/2017/09-08/5/12E/512E9E5E2E9E2F4B980C7E5A67A01F21.DVS
ACCESS Retention SUCCESS V-288-0 Retention value on file /vx/ev_worm_fs/wormpart1/2017/09-08/5/12E/512E9E5E2E9E2F4B980C7E5A67A01F21.DVS is 10-08-2017 01:45:00
access73>
For the above item, the Archiving Policy was set with a Retention of 1 month.
The Archiving Task was launched on 09-08-2017 (8th September) and we can see the file is set with a retention until 8th October.