Veritas Access Solutions Guide for Software-Defined Storage (SDS) Management Platform
- Introduction
- Deploying the SDS Management Platform with Veritas Access
- Using the SDS Management Platform interface
- Setting up SSL in the SDS Management Platform
- Performing authentication
- System backup and restore
- Troubleshooting
- Log locations
- Diagnostic reports
- Java Virtual Machine (JVM) parameters
- SDS Management Platform known issues
- If multiple bucket creation requests with different inputs for attributes such as size and layout are in progress in parallel, then a bucket can get created with incorrect attributes
- When editing a storage resource or backup server, an Advanced button is available that shows options that you should not change
- If you add a Veritas Access cluster where the host includes the protocol (such as, https://10.20.30.40), the provider gets added and collects data but running the LTR workflow fails
- When you create a bucket, the status of the task appears as DONE, even though the creation is still in progress
- Clicking on a non-mapped Veritas Access cluster directs you to an empty wiki page which shows a table and some data
- If you restart the operating system, the SDS Management Platform does not start automatically
- When you add a storage resource or backup server, the added resource is not automatically visible
- After the SDS log is rotated, the log messages from either Veritas Access or the SDS plugin go to the rotated file instead of the new file
- Some of the storage resources may appear as faulted and a warning sign appears next to the cluster IP address in the Infrastructure> Storage Resources page
- Creation of STU fails if the S3 user is changed
- Software limitations
Automatic backups
Complete data backups are performed automatically at regular intervals by the system. The backup path, interval, and number of backups to keep are specified with the following configuration parameters:
backupPath
backupFrequencyInHours
numberOfBackupsToKeep
By default, these parameters are written to a local disk folder called backup, which is located parallel to the installation folder, once every hour, with a rolling window of 100 backups. The oldest backups are removed automatically once the number is arrived at. You can specify the backup path to use a mounted network share rather than the local disk. The service owner or user should have write privileges on that target. Very large data centers can produce large backup files that may consume all the available space on the disk. Hence, the backup folder or disk should be dimensioned accordingly, or the number of retained backups reduced accordingly.
Note:
The backups are of the data only, not the software installation.
The automatic backup is a folder named with a date and timestamp, containing zip files, and all the configuration files required to restore the object database, the RDF datastore, and all instance-specific configuration parameters, providers, and authentication data. The object database (which is in-memory at run-time) is saved to the db-core.zip file, and the RDF datastore, wiki pages, and ontology are saved in the timestamp_diagnosticfeedback.zip file. These files collectively offer a consistent backup set from which the data can be restored to the time of the backup.
Note:
The in-memory DB is persisted at intervals of one minute in between the hourly backups to /db/dbcore.zip.temp.#. If these files are still available after an incident, there is no loss of persisted data. However, all of the data that has originated from providers is reloaded at the next provider run if it is no longer in the database. Hence, it is not critical to maintain the data in this database from backups.