Veritas Access Appliance Administrator's Guide
- Section I. Introducing Access Appliance
- Section II. Configuring Access Appliance
- Managing users
- Configuring the network
- Configuring authentication services
- Configuring user authentication using digital certificates or smart cards
- Section III. Managing Access Appliance storage
- Configuring storage
- Managing disks
- Access Appliance as an iSCSI target
- Configuring storage
- Section IV. Managing Access Appliance file access services
- Configuring the NFS server
- Setting up Kerberos authentication for NFS clients
- Using Access Appliance as a CIFS server
- About configuring CIFS for Active Directory (AD) domain mode
- About setting trusted domains
- About managing home directories
- About CIFS clustering modes
- About migrating CIFS shares and home directories
- About managing local users and groups
- Using Access Appliance as an Object Store server
- Configuring the NFS server
- Section V. Managing Access Appliance security
- Section VI. Monitoring and troubleshooting
- Configuring event notifications and audit logs
- About alert management
- Appliance log files
- Configuring event notifications and audit logs
- Section VII. Provisioning and managing Access Appliance file systems
- Creating and maintaining file systems
- Considerations for creating a file system
- About managing application I/O workloads using maximum IOPS settings
- Modifying a file system
- Managing a file system
- Creating and maintaining file systems
- Section VIII. Provisioning and managing Access Appliance shares
- Creating shares for applications
- Creating and maintaining NFS shares
- About the NFS shares
- Creating and maintaining CIFS shares
- About the CIFS shares
- About managing CIFS shares for Enterprise Vault
- Integrating Access Appliance with Data Insight
- Section IX. Managing Access Appliance storage services
- Configuring episodic replication
- Episodic replication job failover and failback
- Configuring continuous replication
- How Access Appliance continuous replication works
- Continuous replication failover and failback
- Using snapshots
- Using instant rollbacks
- Configuring episodic replication
- Section X. Reference
Enabling WORM on buckets
You can enable WORM on a bucket using the objectaccess bucket worm commands.
objectaccess> bucket worm set [minret] [maxret] <bucket_name>
Where
bucket_name | Specifies the name of the bucket |
minret | Specifies the minimum time period of retention. The format can be: [1-9](s|S|h|H|d|D|m|M|y|Y) |
maxret | Specifies the maximum time period of retention. The format can be: [1-9](s|S|h|H|d|D|m|M|y|Y) |
Note:
This command is not supported in Normal lockdown mode.
You can also list the WORM status, minimum and maximum retention period for a specified bucket. Retention values are in seconds.
objectaccess> bucket worm get
Note:
In Normal lockdown mode, the WORM status appears as "No".
You can set the retention period on objects using the objectaccess object retention commands. If the version ID is provided, retention is set on the object with specified version ID. If version ID is not passed, retention is set on the object with the latest version. In Enterprise lockdown mode, if retention time is given as 0, retention is removed on that object.
objectaccess> object retention set <object_path> <retention_time> [version_id]
Where
object_path | Specifies the path of the object starting with bucket name |
retention_time | Specifies the retention period. The format can be: [1-9](s|S|h|H|d|D|m|M|y|Y) or mm-dd-yyyy or mm-dd-yyyy:hh:mm:ss or 0 |
version_id | Specifies the version ID of the object |
You can also display the retention period on objects. If the version ID is provided, retention period of the object with the specified version ID is displayed. If version ID is not passed, retention period of the object with the latest version is displayed.
objectaccess> object retention get <object_path> [version_id]
Note:
In Normal lockdown mode, the retention status appears as "No retention set".
Note:
Versioning is only supported for WORM buckets.
Table: Non MSDP-C use case describes the supported S3 mode with cluster lockdown mode for a non MSDP-C use case.
Table: Non MSDP-C use case
Normal cluster mode | Enterprise cluster mode | Compliance cluster mode | |
---|---|---|---|
S3 Lock request with Compliance mode | Not allowed | Supported | Supported |
S3 Lock request with Governance mode | Not allowed | Not supported | Not supported |
Table: MSDP-C use case describes the supported S3 mode with cluster lockdown mode for an MSDP-C use case.
Table: MSDP-C use case
Normal cluster mode | Enterprise cluster mode | Compliance cluster mode | |
---|---|---|---|
S3 Lock request with Compliance mode | Not allowed | Not supported | Supported |
S3 Lock request with Governance mode | Not allowed | Not supported | Not supported |
Note:
An administrator can create an S3 bucket which is not WORM-enabled in both enterprise and compliance mode. Administrator can also change mode of existing bucket to WORM-enabled by using the lockdown-mode set command.