Data Domain: Enabling DD Boost API Logging - Precert Logs
Summary: This article explains how to enable the Data Domain Boost (DD Boost) plugin logging when troubleshooting issues related to Boost and BoostFS. This is called a precert log.
Instructions
ddboost_precert.ini file allows for deeper diagnostics. Incorrect file placement, missing permissions, or misconfiguration can prevent log generation.
Reasons to Enable API-Level (precert) Logging:
- DD Boost or BoostFS operations are failing or behaving unexpectedly.
- Engineering or Support requests detailed API-level logs for analysis.
- No logs are generated despite expected Boost activity.
General Notes:
- Only enable precert logging when explicitly requested by Engineering or Support.
- Monitor disk space closely; logs can grow rapidly.
- Ensure correct permissions and file placement.
- Remove the
.inifile to disable logging. - BoostFS must be unmounted and remounted for changes to take effect.
File Locations by OS
| Operating System | ddboost_precert.ini Location |
ddboost_precert.log Location |
|---|---|---|
| Linux | /ddboost_precert.ini |
/DDLog/ddboost_precert.log |
| Solaris | /ddboost_precert.ini |
/DDLog/ddboost_precert.log |
| UNIX | /ddboost_precert.ini |
/DDLog/ddboost_precert.log |
| Windows | C:\ddboost_precert.ini |
C:\DDLog\ddboost_precert.log |
For BOOST and BoostFS Versions Prior to 7.0
Create an empty file named ddboost_precert.ini at the appropriate location (see table above). This enables logging to the default path.
For BOOST and BoostFS Version 7.0 and later
Create a configured ddboost_precert.ini file with the following contents:
precert_enabled=true num_log_files=4 log_file_size=512 log_file_name=ddboost_precert.log log_file_dir=/DDLog ddcl_logs_include=true ddcl_logs_sev=4
- This configuration creates four log files of 512MB each (2GB total).
- Adjust
num_log_filesandlog_file_sizeas required. - Logs can be redirected to a different location if disk space is limited.
Linux BOOSTFS Client Setup
- Create
/DDLogdirectory:
mkdir /DDLog
chmod 777 /DDLog
- Create
/ddboost_precert.iniwith the configuration above.
- Ensure BoostFS is unmounted and remounted:
mount -o log-level=debug <mount_point>
Windows BOOSTFS Client Setup
- Create
C:\ddboost_precert.iniwith the following content:
precert_enabled=true num_log_files=3 log_file_size=500 log_file_name=ddboost_precert.log log_file_dir=C:\DDLog ddcl_logs_include=true ddcl_logs_sev=4
- Create
C:\DDLogand assign full read/write permissions. - Unmount and remount BoostFS with debug logging enabled.
Cleanup and Disabling Logging
- Delete the
ddboost_precert.inifile. - Delete the
DDLogdirectory and its contents. - Remount BoostFS to apply changes.
- Collect BoostFS logs from
/opt/emc/boostfs/log.
Additional Information
Frequently Asked Questions (FAQ)
Question: What is DD Boost Precert Logging?
Answer: DD Boost Precert Logging is a diagnostic logging feature that records DD Boost API transactions between a DD Boost client and the Data Domain system. It is commonly used for troubleshooting performance issues, failures, latency, and communication problems.
Question: What does Precert Logging capture?
Answer: Precert logging captures DD Boost API activity including read operations, write operations, backup activity, restore activity, DD Boost library interactions, API call timing information, and client-side latency indicators. It provides detailed visibility into DD Boost API behavior for troubleshooting and performance analysis.
Question: Why are no precert logs being generated?
Answer: Verify that the ddboost_precert.ini file exists, is located at the operating system root, the log directory exists, the log directory is writable, and a new backup or restore operation has started. Missing configuration, incorrect placement, permission issues, or lack of new DD Boost activity are the most common causes.
Question: Does enabling precert logging immediately generate logs?
Answer: No, log files are generated only when new DD Boost API requests are received. The configuration only enables logging capability.
Question: Why doesn't my currently running backup generate precert logs?
Answer: Precert logging only captures API activity initiated after the configuration is detected. Existing backup or restore jobs continue without generating precert logs.
Question: Do I need to restart my backup or restore job?
Answer: Yes, a new backup or restore job is required to generate precert logs. If the job was already running when logging was enabled, start a new operation.
Question: What is the most common reason precert logging does not work?
Answer: Common causes include ddboost_precert.ini not being at the root level, being accidentally named ddboost_precert.ini.txt, a missing log directory, or insufficient permissions. Configuration and filesystem issues are the most frequent causes.
Question: Where should the ddboost_precert.ini file be placed?
Linux: /ddboost_precert.ini. Windows: C:\ddboost_precert.ini.
Answer: The file must reside in the operating system root directory.
Question: Can the ddboost_precert.ini file be stored in another folder?
Answer: No, the file must be stored at the root. The DD Boost plugin only checks the operating system root directory.
Question: How can I verify the file is not actually
ddboost_precert.ini.txt
Open File Explorer, enable File Name Extensions, and verify the filename.
Answer: Ensure the file is named
ddboost_precert.ini and not ddboost_precert.ini.txt.
Question: Why is the DDLog directory empty after enabling logging?
Answer: Run a new backup, restore, or DDPCONNCHK test to generate activity. Possible causes include no new DD Boost activity, permission issues, or a configuration file that was not detected.
Question: What is DDPCONNCHK and why is it useful?
Answer: DDPCONNCHK is a DD Boost connectivity validation tool. It can generate DD Boost API activity and quickly confirm that precert logging is working.
Question: Can DDPCONNCHK be used to test my configuration?
Answer: Engineers frequently run DDPCONNCHK after enabling logging. Yes, it is a common way to verify logs are being generated before reproducing a problem.
Question: Why are my precert logs growing so quickly?
Answer: Precert logging records every DD Boost API call. Large backup environments can generate significant log volume in a short time.
Question: How much disk space should I allocate? A common recommendation is
num_log_files=3 and log_file_size=500.
Answer: This provides approximately 1.5 GB of log storage before rotation occurs.
Question: Can precert logs fill a filesystem?
Answer: Logging can consume significant disk space if not monitored. Yes, full filesystems can result in backup failures, outages, and service interruptions.
Question: What is the purpose of num_log_files?
Answer: This parameter controls the number of rotated log files retained. For example, num_log_files=3 creates ddboost_precert.log, ddboost_precert.log.1, and ddboost_precert.log.2.
Question: What is the purpose of log_file_size?
Answer: This parameter defines the maximum size of each log file in MB. For example, log_file_size=500 allows each file to grow to 500 MB before rotation.
Question: What does ddcl_logs_include=true do?
Answer: It enables DD Boost Client Library logging information within the precert logs. The recommended setting is ddcl_logs_include=true.
Question: What does ddcl_logs_sev=4 mean?
Answer: This parameter controls logging severity. Severity level 4 provides detailed troubleshooting and debugging information.
Question: Do I need BoostFS debug logging in addition to precert logging?
Answer: Additional logging is not always required. For BoostFS-specific issues, enabling both often provides a more complete diagnostic picture.
Question: For BoostFS, do I need to unmount and remount?
Answer: Unmounting and remounting reinitializes BoostFS activity. In many cases, yes, this helps initiate new DD Boost activity.
Question: What is the correct BoostFS debug logging syntax?
Answer: The correct syntax is -o log-level=debug. Do not use --o log-level=debug because only a single dash is valid.
Question: Why did remounting BoostFS suddenly make precert logs appear?
Answer: Remounting creates a new initialization cycle for BoostFS. Logging begins when new DD Boost API activity occurs and the plugin detects the configuration file.
Question: Is restarting an application equivalent to remounting BoostFS?
Answer: Usually yes, examples include restarting RMAN, backup software, or running DDPCONNCHK. Any action that creates new DD Boost API activity can trigger logging.
Question: Can RMAN generate precert logs without unmounting BoostFS?
Answer: Yes, starting a new RMAN operation is normally sufficient. RMAN can initiate new DD Boost API requests directly.
Question: How do I disable precert logging?
Answer: Delete ddboost_precert.ini or rename it to ddboost_precert.ini.disabled.
Question: Do I need to reboot the host after removing the ini file?
Answer: No, rebooting is not required.
Question: What permissions should be used on Linux? Example permissions include
mkdir /DDLog, chmod 777 /DDLog, and chmod 777 /ddboost_precert.ini.
Answer: The DD Boost process must be able to read the configuration file and write to the log directory.
Question: Where are BoostFS logs stored by default?
Linux: /opt/emc/boostfs/log. Windows: C:\BoostFS\Log.
Answer: These locations are separate from DD Boost precert logs.
Question: Are BoostFS logs and precert logs the same thing?
Answer: No, precert logs contain DD Boost API transactions, library communications, and I/O timing data. BoostFS logs contain mount activity, filesystem operations, and application events.
Question: What logs should I provide to Support?
Answer: Providing all relevant logs helps accelerate troubleshooting. Depending on the issue, collect ddboost_precert.log, rotated precert logs, BoostFS logs, DDPCONNCHK output, application logs, and requested support bundles.
Question: What should I do if logs still are not generated after following this KB?
Answer: Collect evidence such as the ddboost_precert.ini location, log directory listing, DDPCONNCHK output, BoostFS mount command, and permissions information. Submit the collected information to Dell Technical Support for further analysis.