Ransomware attackers specifically target and attempt to destroy backup systems to increase the probability of payment. Hardening your system is critical. Please ensure you have reviewed your platform security using the Security Hardening Checklist
Cohesity

COHESITY Documentation

Explore our documentation to get started, discover products & new features, access troubleshooting guides, register sources, platforms support.

Products
Data Security Alliance
Visit Cohesity.com
Demos
Support
Blogs
Developers
Partner Portals
Cohesity Community
© 2026 Cohesity, Inc. All Rights Reserved.
Terms of Use|
Privacy Policy|
Legal|
  1. Home
  2. Veritas NetBackup™ Deduplication Guide
  3. Configuring deduplication to the cloud with NetBackup CloudCatalyst
  4. NetBackup CloudCatalyst workflow processes
Veritas NetBackup™ Deduplication Guide

NetBackup CloudCatalyst workflow processes

Figure: Workflow on a CloudCatalyst storage server shows the workflow on a CloudCatalyst storage server for uploading data to the cloud.

Figure: Workflow on a CloudCatalyst storage server

Workflow on a CloudCatalyst storage server

Note that a single CloudCatalyst storage server can only write to one cloud provider and to one bucket within that cloud provider.

Filesystem in Userspace (FUSE)

The Filesystem in Userspace (FUSE) forwards data from MSDP to the File System Database (FSDB).

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 Extendable Storage File System (ESFS)

NetBackup CloudCatalyst 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:

  • File system component: Interacts with the ESFS database.

  • 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

Logs the FUSE operations.

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.

MSDP cache files

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 CloudCatalyst esfs.json configuration file.

Backup workflow

Figure: Backup data workflow for a CloudCatalyst storage server

Backup data workflow for a CloudCatalyst storage server
Optimized duplication workflow

Figure: Optimized duplication workflow with target as a CloudCatalyst storage server

Optimized duplication workflow with target as a CloudCatalyst storage server

Feedback

Was this page helpful?
Previous

Decommissioning CloudCatalyst cloud storage

Next

Disaster Recovery for CloudCatalyst

Feedback

Was this page helpful?