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
- About MSDP Encryption using KMS service
- 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
- About NetBackup Auto Image Replication
- Configuring a target for MSDP replication to a remote 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 Cloud Catalyst
- Using NetBackup Cloud Catalyst to upload deduplicated data to the cloud
- Configuring a Cloud Catalyst storage server for deduplication to the cloud
- Monitoring deduplication activity
- Viewing MSDP job details
- 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 Cloud Catalyst issues
- Cloud Catalyst logs
- Problems encountered while using the Cloud Storage Server Configuration Wizard
- Disk pool problems
- Problems during cloud storage server configuration
- Cloud Catalyst troubleshooting tools
- Appendix A. Migrating to MSDP storage
NetBackup Cloud Catalyst workflow processes
Figure: Workflow on a Cloud Catalyst storage server shows the workflow on a Cloud Catalyst storage server for uploading data to the cloud.
Note that a single Cloud Catalyst storage server can only write to one cloud provider and to one bucket within that cloud provider.
The Filesystem in Userspace (FUSE) forwards data from MSDP to the File System Database (FSDB).
The File System Database (FSDB) tracks and stores metadata about all of the files that are written to the NetBackup Extendable Storage File System (ESFS).
NetBackup Cloud Catalyst uses the NetBackup Extendable Storage File System Service (vxesfsd) and its subcomponents to move and manage files in the local cache directory and the cloud.
ESFS uses daemons to perform the following functions in its database:
Veritas NetBackup Extendable Storage File System Service daemon (vxesfsd): This process is the primary file system daemon. This process is responsible for writing data into the MSDP cache files.
Open Cloud Storage Daemon (ocsd): This daemon is responsible for interacting with the cloud. Under normal circumstances, there is only one ocsd process running.
The ocsd daemon produces the following log: /usr/openv/netbackup/logs/esfs_storage
vxesfsd includes three subcomponents that perform various tasks as part of ESFS:
Monitor component: The monitor component checks the file queue for files to be uploaded and checks the local cache directory for cache eviction purposes, among other activities.
Storage manager component: Notifies ocsd processes when there's work to be done. Some of the activities that this component manages are synchronous (downloads from the cloud), asynchronous (uploads to and deletions in the cloud), and shared memory.
The vxesfsd daemon produces the following logs in /usr/openv/netbackup/logs/:
esfs_filesystem | |
esfs_storagemanager |
Logs the interactions of the ESFS storage manager with vxesp. |
esfs_monitor |
Logs the job status updates and periodic tasks such as cache eviction and FSDB backups. |
esfs_database |
Logs the FSDB actions that are specific to the ESFS database. |
As part of the Cloud Storage Server Configuration Wizard, the administrator configures a local cache directory ( local_cache_dir ). The directory must be on either a Linux file system or, in the case of an appliance, a VxFS file system.
The directory is then split into two:
A cache directory: local_cache_dir/cache/userdata
ESFS writes out the data and the metadata in this location. This directory is mapped directly to the storage directory ( local_cache_dir/storage). Two copies of each file do not exist on this media server.
A storage directory: local_cache_dir/storage
This path is the mount point to the ESFS file system. This path is what MSDP knows as its storage directory.
NetBackup periodically performs data eviction tasks in the cache directory to create space for new backups. If necessary, the administrator can change when or how often data eviction occurs. These options are configured in the esfs.json file.
See About the Cloud Catalyst esfs.json configuration file.