Veritas NetBackup™ Deduplication Guide
- Introducing the NetBackup media server deduplication option
- Planning your deployment
- About MSDP storage and connectivity requirements
- About NetBackup media server deduplication
- About NetBackup Client Direct deduplication
- About MSDP remote office client deduplication
- About MSDP performance
- MSDP deployment best practices
- Provisioning the storage
- Licensing deduplication
- Configuring deduplication
- Configuring the Deduplication Multi-Threaded Agent behavior
- Configuring the MSDP fingerprint cache behavior
- Configuring MSDP fingerprint cache seeding on the storage server
- Configuring a storage server for a Media Server Deduplication Pool
- Configuring a disk pool for deduplication
- Configuring a Media Server Deduplication Pool storage unit
- About MSDP optimized duplication within the same domain
- Configuring MSDP optimized duplication within the same NetBackup domain
- Configuring MSDP replication to a different NetBackup domain
- Creating a storage lifecycle policy
- Resilient Network properties
- Editing the MSDP pd.conf file
- About protecting the MSDP catalog
- Configuring an MSDP catalog backup
- Configuring deduplication to the cloud with NetBackup CloudCatalyst
- Using NetBackup CloudCatalyst to upload deduplicated data to the cloud
- Configuring a CloudCatalyst storage server for deduplication to the cloud
- Monitoring deduplication activity
- Managing deduplication
- Managing MSDP servers
- Managing NetBackup Deduplication Engine credentials
- Managing Media Server Deduplication Pools
- Changing a Media Server Deduplication Pool properties
- Configuring MSDP data integrity checking behavior
- About MSDP storage rebasing
- Managing MSDP servers
- Recovering MSDP
- Replacing MSDP hosts
- Uninstalling MSDP
- Deduplication architecture
- Troubleshooting
- About unified logging
- About legacy logging
- Troubleshooting MSDP installation issues
- Troubleshooting MSDP configuration issues
- Troubleshooting MSDP operational issues
- Troubleshooting CloudCatalyst issues
- CloudCatalyst logs
- Problems encountered while using the Cloud Storage Server Configuration Wizard
- Disk pool problems
- Problems during cloud storage server configuration
- CloudCatalyst troubleshooting tools
- Appendix A. Migrating to MSDP storage
About the CloudCatalyst esfs.json configuration file
The NetBackup CloudCatalyst uses the configuration options that are included in the esfs.json file for many operations, including options that determine when data is uploaded to cloud storage or when it is evicted from the local cache. Some of the options are configurable by the NetBackup administrator. The location of the esfs.json file depends on the location of the local cache directory.
As part of the Cloud Storage Server Configuration Wizard, the administrator configures a local cache directory. The local cache directory (local_cache_dir in the following topic) determines the location of other directories which are installed automatically and are critical to CloudCatalyst operations:
The NetBackup CloudCatalyst configuration options are listed in Table: Configuration items in the esfs.json file.
To change the configuration items in the esfs.json configuration
- Change one or more of the configuration items in the esfs.json file. The file is found in the following location:
local_cache_dir/cache/etc/esfs.json
- Save and close the file.
- If vxesfsd is running, run the esfs_reconfig command, indicating the mount path, as follows:
/usr/openv/esfs/bin/esfs_reconfig local_cache_dir/storage
If esfs.json is changed while vxesfsd is stopped, the changes take effect the next time vxesfsd starts.
- Some items require that you restart vxesfsd before the new configuration can take effect.
These items are indicated in Table: Configuration items in the esfs.json file.
Before stopping vxesfsd, make sure that no processes are using vxesfsd, including the current working directory of any user.
The NetBackup Deduplication Manager (spad) and the NetBackup Deduplication Engine (spoold) use vxesfsd, so they need to be stopped if either is running.
Before starting vxesfsd, make sure that no data exists in the mount point. If data exists in the mount point, vxesfsd fails to restart.
The following topic contains additional information about restarting vxesfsd:
Table: Configuration items in the esfs.json file
Configuration item | Default setting | Description | vxesfsd restart required? |
---|---|---|---|
Log | |||
Path | \/usr\/openv\/netbackup\/logs | This setting indicates the directory where logs for the vxesfsd process are created. The logs include the following:
| Yes |
\/usr\/openv\/esfs\/logs\/ops |
| ||
Size | 10485760 | This value (in kilobytes) controls the maximum size that a single log file is allowed to grow. Once the file reaches that approximate size, the log file is closed and another log file is opened. | No |
Level | This value determines the logging level and what information is included in the logs:
| Yes | |
Monitor | |||
DACDays | The Delete After Close Days value determines how long a container file remains in the cache after it is last accessed and then closed. After the specified number of days, vxesfsd removes the file from the cache directory only if it has been successfully uploaded to the cloud. This commonly occurs shortly after midnight where the CloudCatalyst storage server is located. Files which have not been successfully uploaded to the cloud are not removed from the cache directory. | No | |
HighWatermark | This value determines how full the cache partition is allowed to grow before vxesfsd begins to evict container files. The value represents the percentage of used space on the cache partition. The oldest files are evicted until the LowWatermark is met. Files that have not been successfully uploaded to the cloud are not removed from the cache directory by the eviction process. If the HighWatermark value is set very low, the cache is nearly cleared. That is, nearly all of the eligible files are evicted. Note: The file system on which the cache resides must not contain data from any other applications. | No | |
LowWatermark | This value determines at what point vxesfsd stops evicting container files after the HighWatermark triggers eviction. The value represents the percentage of used space on the cache partition. | No | |
BackupDBTime | 12 | This value determines how frequently (in hours) the database is backed up. This value is unrelated to the drcontrol policy, if one exists. Veritas recommends that a drcontrol policy is created and used to protect your cloud storage server. Veritas recommends that this value is not changed. Note: This is a special database for the cloud storage server, not the NetBackup or MSDP catalog. | No |
StorageManager | |||
IOSize | 1048576 | This value (in bytes) has been used for internal testing. Veritas recommends that this value is not changed. | No |
UploadThreads | This value determines the number of threads available for uploading data to the cloud. | Yes | |
DownloadThreads | This value determines the number of threads available for downloading data from the cloud. | Yes | |
BackupDBCopies | 14 | This value determines the maximum number of saved copies of the database that will be created for backup. Veritas recommends that this value is not changed. This value is unrelated to the drcontrol policy, if one exists. Veritas recommends that a drcontrol policy is created and used to protect your cloud storage server. Note: This is a special database for the cloud storage server, not the NetBackup or MSDP catalog. | No |
FileSystem | |||
MaxOpenFile | 192114 | This value determines the maximum number of files that can be open at one time. Veritas recommends that this value is not changed. | Yes |
ReadOnly | This value indicates whether the files currently stored in the cloud can be modified:
This setting is used for disaster recovery and should not be changed under normal usage. | Yes |