Troubleshooting
Error "local error: tls: record overflow"
Description: This error indicates a network corruption issue that led to the closure of the connection by Zmanda Pro's network library.
Common Causes:
Random network disruptions.
Hardware issues such as failing Network Interface Cards (NIC) or faulty RAM.
Outdated or improperly configured network devices like firewalls or proxies that might perform incorrect SSL interception.
Resolution:
Retry the Operation: Often, simply retrying can bypass temporary network issues.
Inspect Network Hardware: Check the NIC and RAM on involved devices, including routers.
Update Network Devices: Ensure firewalls or proxies are up to date and correctly configured.
For detailed protocol specifications, refer to the record_overflow
section in IETF RFC 5246.
"Paused" state on Windows service
Description: This state indicates that the Zmanda Pro Server service repeatedly failed to start, leading Windows to cease attempts to restart it.
Resolution Steps:
Check Logs:
Access the log files via the Service Manager on the server's administration console, or navigate to the file path
C:\ProgramData\Zmanda\logs
to manually review the logs.Look for log entries around the time the unexpected backup was initiated, focusing on indications of startup triggers, missed backup executions, network reconnections, and relevant errors or warnings.
Identify the Error: Locate the error in the most recent log file to understand why the service is failing to start.
Resolve the Underlying Issue: Address the specific error identified in the logs to resume normal operation.
Microsoft SQL Server backup encountered a VDI error
Description: Errors during SQL Server backups usually involve issues with the Virtual Device Interface (VDI) .dll files.
Resolution:
Verify VDI .dll Files: Ensure these files are properly registered and compatible with your SQL Server version. ou can use Microsoft SQL Server Backup Simulator to check the status of the VDI
.dll
files.Use Diagnostic Tools: Employ tools like the Microsoft SQL Server Backup Simulator to check the status of the VDI components.
Error "Access is denied" when backing up files and folders on Windows
Description: This error occurs when Zmanda Pro does not have the necessary permissions to read files or directories during a backup.
Potential Causes:
The service account lacks necessary permissions.
Attempting to back up a network path mounted as a directory.
Resolution:
Verify Service Account Permissions: Ensure the service account used by Zmanda Pro has sufficient permissions.
Network Shares and UNC Paths: Check access rights for network paths if applicable.
Adjust Backup Delegate Service: If the error relates to local protected items, modify the backup delegate service to 'log on as' an account with the required access.
Antivirus Interactions with Zmanda Pro
False Positive Detection of Zmanda Pro as Malware
Overview: Due to its nature as a backup solution that installs system services and manages data across networks, Zmanda Pro may occasionally be flagged as a potential threat by antivirus programs. This is commonly a false positive.
Recommended Actions:
Update Antivirus Software: Ensure that your antivirus solution is up-to-date to reduce the likelihood of false positives.
Report to Support: If Zmanda Pro is flagged, capture and send a screenshot of the antivirus alert to Zmanda Support for further assistance.
Whitelisting: Add Zmanda Pro to the allowed list in your antivirus program. This not only prevents further false detections but may also inform the antivirus vendor of the software’s legitimacy.
Authenticode Signing: Implementing Authenticode signing for Windows installations of Zmanda Pro can enhance its reputation with antivirus solutions, verifying the software's integrity and origin.
Error Handling: "backup-tool.exe couldn't be launched. CreateProcess() failed: Access is denied"
Description: This error typically occurs when an antivirus program blocks Zmanda Pro’s backup-tool.exe from executing, mistaking it for a malicious application.
Resolution:
Antivirus Whitelisting: Follow the recommended steps for adding Zmanda Pro to your antivirus program’s whitelist to ensure it recognizes backup-tool.exe as a safe application.
Verify Permissions: Check that all permissions are correctly set for Zmanda Pro’s operation, especially in environments with strict security controls.
Avast "FileRepMalware" Alert
Overview: The "FileRepMalware" error from Avast targets files that:
Were downloaded from the internet.
Lack an Authenticode certificate.
Are not widely recognized by many Avast users.
Resolution:
Authenticode Certificate: Purchase and install an Authenticode certificate for your Zmanda Pro installers to enhance their trustworthiness and reduce false positives from Avast.
Bitdefender Alerts on Zmanda Pro
Bitdefender may incorrectly flag the Zmanda Pro desktop client as a threat.
Resolution:
Create Exclusion Policy: Implement an exclusion policy within Bitdefender for Zmanda Pro files and processes to prevent these false alerts.
Setting Up Installation File Exclusions
For Safe Installation: To ensure smooth installation and operation, define exclusions in your antivirus settings for Zmanda Pro installation files and directories.
Recommended Exclusions:
Folders:
C:\example\*
Files:
C:\example\*
C:\Windows\Temp\*\*\install.exe
C:\Users\*\AppData\Local\Temp\install.exe
Processes:
C:\example\install.dat
C:\example\install.exe
C:\Windows\Temp\*\*\install.exe
C:\Users\*\AppData\Local\Temp\install.exe
Desktop Client Usage Exclusions
To Prevent False Flags by Bitdefender: Define these exclusions specifically for Zmanda Pro's operational files and processes.
Folders:
C:\Program Files\PRODUCTNAME\*
Files:
C:\Program Files\PRODUCTNAME\*
C:\Users\*\Desktop\PRODUCTNAME.lnk
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\PRODUCTNAME.lnk
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\PRODUCTNAME (Background Tasks).lnk
Processes:
Include all executable files related to Zmanda Pro operations, such as backup-interface.exe, backup-service.exe, uninstall.exe, etc., located under
C:\Program Files\PRODUCTNAME\
.
Network Connectivity Troubleshooting
Types of Errors Encountered: While uploading files to the Zmanda Server or a cloud storage provider, you might encounter errors such as:
"HTTP/1.x transport connection broken"
"net/http: request canceled (Client.Timeout exceeded while awaiting headers)"
"wsarecv" or "wsasend"
"An existing connection was forcibly closed by the remote host"
"dial tcp: lookup [...]: no such host"
"connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond."
After a failed data chunk upload, further errors like "Couldn't save data chunk: context canceled" may appear as Zmanda Pro terminates other ongoing upload threads.
Potential Causes:
Issues with the customer’s PC, network, or ISP.
Broad internet outages affecting connections between customer and service ISPs.
Problems within your own network, ISP, or server hardware/software.
Troubleshooting Steps:
Retry the Backup: Many network errors are transient. A retry often resolves the issue, especially since existing data chunks might not need re-uploading.
Check Timing of Errors: Identify if errors occur at specific times, possibly indicating peak internet usage. Rescheduling backups may help.
Review Server Logs: Look for messages like "Error saving upload stream" or "Blocking re-upload of preexisting file" in the Server logs to diagnose issues.
Accessing Windows network shares and UNC paths
Challenges with Network Drives and Authentication:
Zmanda Pro can back up data from network paths or to network storage using SMB/CIFS. Running as a service, Zmanda Pro might face authentication issues, which are critical to address for effective backups.
Mapped network drives
Each Windows user session has its own mapped network drives, which are not available to the service user account. Errors like "WARNING Missing: 'Z:'" indicate missing network mappings for the service account. Use UNC paths instead to resolve this.
Handling Authentication
If a UNC share requires authentication and Zmanda Pro is running as a service user, you might see errors like "WARNING Lstat: CreateFile \?\UNC...: Access is denied."
Latest versions Zmanda Pro has built-in options to manage Windows network authentication credentials effectively.
Error "A specified logon session does not exist...
Description:
"A specified logon session does not exist. It may already have been terminated" typically occurs when accessing a Windows network share due to SMB servers not handling multiple SMB logins with the same credentials from different user accounts simultaneously.
Resolving SMB Session Errors:
Ensure different SMB sessions aren't conflicting by managing network logins carefully.
Adjust backup settings to avoid concurrent access issues, or switch to backup protocols like S3, SFTP, or WebDAV that handle credentials more flexibly.
Verifying the issue
Each Windows user, including the "Run as Administrator" session, maintains separate network login credentials. This setup can impact how Zmanda Pro accesses network shares.
Steps to Verify Network Access:
Test Network Share Accessibility: Attempt to open a network share through both a standard and an elevated (administrator) session using applications like Notepad. This helps verify if network permissions are correctly set across user sessions.
Check Active Network Sessions: Use the command prompt to run
net use
and check if the interactive user account is connected to the network share. This can identify if sessions are being held open unnecessarily.Session Disconnection Test: Execute
net use \\server_name\share_name /DELETE
to forcefully log off the network share and test if this action allows Zmanda Pro to proceed with the backup. Be cautious as this could disrupt the interactive user’s session.
Workarounds for Network Share Issues
Direct Installation on Network Devices:
For optimal performance and fewer network issues, install Zmanda Pro directly on network devices such as NAS systems (e.g., using a Synology SPK installer). This reduces data transfer across the LAN and minimizes access latency.
Managing Network Sessions for Backup:
Pre-Backup Session Management:
Log out the interactive user from Windows before starting the backup to ensure their network sessions are closed. This preparation allows Zmanda Pro to establish its own network connections without interference.
Alternatively, use the Windows Task Scheduler to run
net use /DELETE
before the backup window to disconnect the interactive user’s network sessions.
Post-Backup Session Management:
After the backup, re-establish the interactive user’s network session using Task Scheduler with
net use
commands to restore their connectivity.
Using Alternative Protocols for Backup Targets:
If backing up to an SMB server presents persistent issues, consider enabling alternative transfer protocols like SFTP or configuring a Minio S3-compatible storage system. These methods allow for explicit credential management and can bypass some SMB-related problems.
Implementing Task Scheduler Commands:
Set up Task Scheduler to automate the
net use /DELETE
command before and after backup jobs. Ensure these tasks are configured to run only when the user is logged on, maintaining session integrity.
Error "Couldn't take snapshot: The specified object was not found" with DESlock+
Overview: This error can occur when software elevates its privileges or runs under the System user account, which may result in losing access to encryption keys necessary for accessing encrypted containers.
Common Scenario:
Zmanda Pro operates under service accounts like "NT SERVICE\backup.delegate" or "LOCAL SYSTEM," which may not have access to DESlock+ virtual drives configured for user-specific encryption keys.
Solution:
Global Mounting of Virtual Disks: Utilize the DESlock+ command-line tool to mount virtual disks globally. This ensures that all system users, including service accounts, can access the encrypted contents. Follow the detailed instructions provided by DESlock+ to configure this setting properly.
Detailed guidance can be found on the DESlock+ support page.
Error "VSS Error ... The shadow copy provider had an unexpected error"
Overview: VSS errors typically indicate problems with the VSS provider, which is essential for creating consistent point-in-time snapshots of disks.
Possible Causes and Solutions:
Incompatible VSS Providers:
Check for inappropriate VSS providers that might not match your current hardware setup, especially if hardware has been changed (e.g., migration from Hyper-V to VMware).
Use
vssadmin list providers
to review and manage installed VSS providers.
Force Default VSS Provider:
Modify the registry to enforce the usage of Microsoft’s default VSS provider:
Restart the
backup.delegate
andbackup.elevator
services after applying changes.
Shadow Storage Configuration:
Check and adjust the shadow storage space on the source drives using:
vssadmin list shadowstorage vssadmin Resize ShadowStorage /For=X: /On=X: /Maxsize=XX%
Manage Concurrent Snapshots:
Ensure no other snapshot processes are running simultaneously. If necessary, restart the Volume Shadow Copy Service:
net stop vss net start vss
A system reboot may also help clear lingering issues with the snapshot manager.
Avoid VSS on Network Drives:
VSS cannot be used on mapped network drives. Ensure backups are targeting local storage or supported network protocols.
Conflict with Other Backup Solutions:
Check for and resolve conflicts with other installed backup products, which might have proprietary snapshot managers interfering with VSS operations.
Check VSS Writers:
Validate the functionality of all VSS writers:
vssadmin list writers
Email delivery failed with MX Direct
When using the MX Direct feature, Zmanda Pro acts as a Mail Transfer Agent (MTA), directly delivering emails to recipients' servers. To ensure successful delivery and prevent emails from being marked as spam, certain configurations are crucial.
Understanding IP block reputation
Issue:
Your server's IP may be listed on email spam denylists, particularly if you are using a cloud-based service where IP addresses are recycled.
Resolution:
Request Removal: If your IP is blacklisted, follow the procedures provided by the IP reputation service to request removal.
Configuring Forward-confirmed reverse DNS (FCrDNS)
Importance:
FCrDNS verifies that the IP address is associated with a credible domain, which is a significant anti-spam measure.
Setup:
Verify Reverse DNS Setup: Ensure that the reverse DNS for your IP matches your domain. This involves setting up a TXT record for the reverse IP that correctly resolves back to your domain.
Contact ISP or Host: If you cannot modify the RDNS record directly, contact your ISP or hosting provider to make the necessary changes.
Learn more about FCrDNS from Wikipedia.
Sender Policy Framework (SPF)
Purpose:
SPF allows your domain to specify which mail servers are permitted to send emails on its behalf, preventing unauthorized use of your domain in email headers.
Configuration:
Add SPF Record: Include an SPF record in your domain’s DNS settings to list authorized mail servers. This is particularly important if you already have mail services like Office 365 or G Suite.
Example SPF record:
v=spf1 include:yourserver.example.com ~all
DKIM signing
Overview:
DomainKeys Identified Mail (DKIM) provides a way to validate a domain name identity associated with a message through cryptographic authentication.
Current Support:
As of now, Zmanda Pro's built-in MTA does not support DKIM signing. Without this feature, some email servers might scrutinize the authenticity of your emails more rigorously.
Jobs left in Running state, Cancel a running job
Jobs in Zmanda Pro may remain in a "Running" state indefinitely if the system is shut down unexpectedly. This section outlines methods to resolve and prevent jobs from being stuck.
Automatic Cleanup: Zmanda Pro periodically checks for jobs that are no longer active and automatically cleans up these "Running" jobs if it detects they are inactive.
Manual Cleanup Methods:
Exclusive Vault Actions:
Perform exclusive actions against the Storage Vault, such as reindex operations or retention passes, which require the system to verify that no other jobs are running.
Initiate a New Backup Job:
Starting a new backup job on the same device can help clear stuck jobs by comparing lockfiles in the Storage Vault against active process IDs in the Task Manager.
Software Update:
Running a software update that includes a change in the version number can force termination of all prior jobs, ensuring that all backup processes are reset.
Note:
Commands executed before or after backup jobs may stall, impacting the ability to cancel jobs directly. If these commands do not complete, they may need to be manually terminated from the system's detail view in the Task Manager.
Out of memory
Memory Requirements: Zmanda Pro's memory usage primarily depends on the size of the Storage Vault due to the need to maintain deduplication indexes.
Common Memory Errors:
Windows: "VirtualAlloc of 1048576 bytes failed" or "ERROR_COMMITMENT_LIMIT"
Linux: "fatal error: out of memory", or processes killed by the OOM Killer, checkable via
dmesg
orkern.log
.
Strategies to Reduce Memory Usage:
Optimize Storage Vaults:
Distribute data across multiple Storage Vaults to reduce the load and memory usage on any single vault.
Trade-offs in Memory Management:
Rescan Unchanged Files: Increases data reading from the source, potentially reducing the amount of data loaded into memory.
Prefer Temporary Files Over RAM: Uses on-disk database files for indexing, which reduces RAM usage but can significantly affect performance due to increased disk I/O.
Performance Considerations:
Using disk-based indexes reduces RAM usage but may lead to a major performance penalty (up to 5x slower). This trade-off should be carefully considered based on the backup system’s operational requirements and available system resources.
Change of hardware causes registration dialog to appear
Zmanda Pro identifies each device using a unique hardware ID. Changes to your system's hardware or software configuration can alter this ID, causing Zmanda Pro to recognize the device as new. Common changes that can affect the hardware ID include:
Replacing the motherboard or CPU.
Upgrading BIOS/UEFI settings without preserving hardware IDs.
Virtualizing a physical server.
Migrating a VM guest to a different VM host.
Installing sandboxing or security software with sandbox features (e.g., Comodo Containment).
Making specific modifications to the operating system.
Steps to Handle a Changed Device ID
Re-registering the Device:
If Zmanda Pro recognizes your system as a new device due to hardware ID changes, you will need to register it again within the system.
Preserving Backup Data:
The original backup data remains intact in the Storage Vault and will continue to be deduplicated against any new backups made from the re-registered device.
Transferring Protected Item Settings:
You can transfer settings from one device to another using the Copy/Paste functions available in the Zmanda Pro Server web interface under the user's page > Protected Items tab.
Revoking the Old Device:
To avoid unnecessary licensing fees, revoke the old device once the new device is fully configured. Alternatively, removing all Protected Items from the old device setup will also prevent it from incurring further charges.
Accessing Historical Backup Logs:
Backup job logs will remain linked to the old device but can still be accessed in the Zmanda Pro Server interface or through Zmanda Pro by filtering for "All devices".
After deregistering the original device, it will appear as "Unknown device (XXXXX...)" in the job history.
Implications for Billing:
Recognizing a system as a new device due to hardware changes will reset the billing period for that device, aligning it with the new registration status.
Best Practices
Regular Backups: Ensure regular backups are scheduled to minimize data loss between hardware modifications and re-registration.
Document Changes: Keep a record of hardware and software changes to track their impacts on system registration and backup procedures.
Monitor Registrations: Regularly review device registrations in Zmanda Pro to ensure all devices are correctly recognized and actively backed up.
Storage Vault Locks
Lock files are a crucial component of Zmanda Pro’s design, used to maintain data consistency during concurrent operations across multiple devices.
Functionality:
During a backup, Zmanda Pro checks for existing data chunks in the Storage Vault and uploads new chunks as needed.
During a retention pass, the system first identifies existing data chunks and then deletes those that are unused.
It is safe for multiple backup jobs to run simultaneously, including across different devices.
Lock files
To monitor ongoing operations, Zmanda Pro creates a temporary text file in the Storage Vault at the start of each job and deletes it upon completion.
This file serves as a signal to other processes about active operations, ensuring that no two operations conflict.
Zmanda Pro uses a mark-and-sweep algorithm that allows backup and retention jobs to operate concurrently without risk, enhancing the system's efficiency and safety.
Challenges and Solutions with Lock Filesn
Potential Issues:
If Zmanda Pro terminates unexpectedly (e.g., due to a system crash), lock files may not be removed, potentially causing subsequent operations to falsely detect ongoing activities.
Error Messages and Troubleshooting:
Errors such as "Locked by user '...' on this device (PID #...) since ... (... days ago)" indicate stale lock files.
Before deleting any lock files, ensure the process they relate to is indeed no longer running to avoid data loss.
Safe Removal of Lock Files:
If investigation confirms that the process associated with a lock file has stopped and will not resume, it is safe to manually clear these files.
Lock files can be cleaned from within Zmanda Pro under the "Account" pane by selecting the Storage Vault, right-clicking, and choosing "Clean up lock files."
Administrators can also manage lock files remotely via the Zmanda Server web interface.
Best Practices
Regular Monitoring:
Regularly check for and manage stale lock files, especially after unexpected shutdowns or errors.
System Configuration:
Ensure systems are configured to minimize unexpected disruptions (e.g., preventing system sleep during critical operations).
Documentation and Training:
Maintain clear documentation and train staff on how to handle lock files and related errors, ensuring they understand the implications and proper steps for resolution.
Error "Found X packs in index but not appearing on disk. Reindex needed!"
Problem Overview: This error indicates a discrepancy between the indexed data chunks and those physically present in the Storage Vault. Possible causes include manual deletions, storage platform failures, unsafe operations, or issues arising from retention passes.
Steps to Resolve:
Enable Advanced Options:
Navigate to
Admin -> Advanced Options
.
Initiate Reindex:
Go to
Accounts -> Users -> [User Name] -> Devices tab -> click 'Online' -> Storage Vault tab -> Reindex
.
Apply Retention Rules:
Once reindexing is complete, apply retention rules by navigating to
Accounts -> Users -> [User Name] -> Devices tab -> click 'Online' -> Storage Vault tab -> Apply Retention Rules Now
.
Review Job History:
Check the last job report under
Accounts -> Users -> [User Name] -> Actions -> View Job History -> 'Report'
to confirm that the reindex successfully resolved the issue.
Final Verification:
An absence of errors in the job report indicates that missing data chunks have been properly reindexed. If errors persist, further investigation into the specific issues mentioned in the error messages is required.
Error "<packindex/pppppppp> says <snapshot/ssssssss> depends on missing pack <data/dddddddd>, non-restorable!"
This error signifies that a specific backup snapshot refers to data chunks that are missing from the Storage Vault, rendering the snapshot non-restorable.
Resolution Steps:
Identify and Remove Problematic Packindex:
Navigate to the Storage Vault location as detailed in the system logs or user settings.
Find and delete the problematic 'packindex' file indicated in the error message.
Run a Retention Pass:
After removing the packindex file, run a retention pass to recalibrate and regenerate the index files, ensuring all data references are accurate.
Recovery and Cleanup:
If the retention pass fails to find the missing chunks, it may be necessary to remove the unrecoverable snapshots to maintain the integrity of the Storage Vault.
Use caution when deleting snapshots; ensure all other recovery methods have been exhausted.
Logging and Documentation:
Document all steps taken during the troubleshooting process, and maintain logs for future reference in case of recurrent issues.
General Advice for Managing Data Integrity Issues:
Regular Checks: Regularly verify the integrity of data within Storage Vaults to catch and resolve issues before they impact backups.
Backup Strategy: Maintain a robust backup strategy that includes regular snapshots and multiple Storage Vaults to mitigate potential data loss.
System Updates: Ensure that all system components are up to date to avoid bugs or incompatibilities that might lead to data integrity issues.
Backup process stalled on "Preparing Storage Vault for first use"
When initializing a new Storage Vault, Zmanda Pro generates and stores encryption material. If the backup process stalls at this stage, it may indicate issues accessing the storage location, often due to configuration errors or network problems.
Common Causes and Solutions
Storage Vault Misconfiguration:
For Server Buckets: Verify the "Hostname" field in the Storage Vault properties. Ensure it points to a valid URL and does not reference localhost (127.0.0.1) or an incorrect IP.
For Cloud Buckets: Double-check the cloud bucket credentials. Ensure there are no trailing spaces or formatting errors in the credential fields.
Outdated CA Certificates:
This can prevent HTTPS/SSL connections to the storage location.
On Windows: Run Windows Update to refresh the CA certificates.
On Linux: Update the
ca-certificates
package to ensure your system trusts the latest certificate authorities.
Errors accessing virtual cloud storage files
OneDrive Configuration:
OneDrive and similar services may store files virtually on-demand, which poses unique challenges for backup processes, especially when using VSS (Volume Shadow Copy Service).
Errors and Workarounds:
"Media is write protected": Occurs when VSS snapshots prevent downloading files during the backup. Split backup tasks into two:
One task with VSS enabled, excluding the OneDrive directory.
One task with VSS disabled, specifically for backing up OneDrive.
"Access to the cloud file is denied": Indicates that the virtual filesystem is refusing to download files on-demand for backup. Disabling "Files-On-Demand" in OneDrive's settings can mitigate this, though it increases local disk usage.
Google Drive and Google File Stream:
Google File Stream creates a virtual drive (e.g., G:) that is not visible to the service user account used by Zmanda Pro for backups.
Potential Solution: Consider third-party tools like StableBit CloudDrive or 'rclone mount' to mount Google Drive as a lettered drive accessible to all users. However, backing up in this manner might lead to significant inbound network traffic as files are downloaded.
Additional Tips
Monitor and Log: Regularly check the system logs and backup reports to understand the status of the backups and any errors that occur.
Consult Network and System Admins: If network-related issues are suspected, involve your IT support to ensure no network policies or firewall settings are blocking the backup operations.
Documentation and Training: Maintain up-to-date documentation of your backup configurations and ensure that all relevant staff are trained on how to manage and troubleshoot the backup system.
Warning "EFS-encrypted files may be unusable once restored..."
Issue Overview: Encrypted File System (EFS) is a Windows feature that encrypts individual files linked to a user account. While backups may succeed, restoring these files on a different PC might render them unreadable without the corresponding EFS encryption keys.
Solution:
Backup EFS Keys: Ensure that EFS encryption keys are backed up along with the files. This is crucial for restoring the encrypted files on any new system.
Disable Warning: Once the EFS keys are backed up, you can dismiss future warnings by ticking the 'Dismiss the EFS warning' option in the Protected Item settings.
Error "The targt path 'X:\WindowsImageBackup' already exists..."
Problem Statement: This error occurs if the target directory for a system backup already exists, which could be due to an incomplete previous backup, concurrent backup operations, or other software using the same backup mechanism.
Resolution Steps:
Manual Cleanup: Safely remove the
X:\WindowsImageBackup
directory if it's left from an incomplete backup.Automation Script: Temporarily add a PowerShell command as a "Before" command in the backup job to check and clear the directory:
powershell -command "if (Test-Path -Path 'X:\WindowsImageBackup') { Remove-Item -Recurse -Force 'X:\WindowsImageBackup'}"
Remove this command after it runs to prevent potential conflicts with future backups.
Error "too many open files"
This common error indicates the system has reached its limit for open file handles, which are critical for managing open files and network connections. Here's how to address and prevent it:
On macOS
System and Per-Process Limits:
View Current Limits:
System-wide: Run
sysctl kern.maxfiles
.Per-process: Run
sysctl kern.maxfilesperproc
.
Increase Limits:
For macOS 10.12 and later: Create a
.plist
file in the/Library/LaunchDaemons/
directory specifying the new limits.For macOS 10.11 and earlier: Modify
/etc/sysctl.conf
to include new limit values and apply changes withsudo sysctl -p
.
On Linux
System-wide and Per-Process Limits:
View and Modify System-wide Limits:
View:
cat /proc/sys/fs/file-max
.Modify: Use
echo "fs.file-max=10485760" >> /etc/sysctl.conf
andsudo sysctl -p
to apply.
Per-Process Limits:
View current limit:
ulimit -n
.Increase limit:
ulimit -n 10485760
for a temporary increase, or permanently modify/etc/security/limits.conf
.
On Windows
Handle and Network File Limits:
View and Adjust Handle Limits:
Use Task Manager to view current handle usage.
Adjust using Group Policy for system-wide settings.
Network Files:
Check session limits with
net config server
and adjust for higher capacity if needed.
Error: "Couldn't decrypt Vault contents"
Occurs when there's a mismatch between the encryption key and the vault contents. Detailed steps to resolve:
Verification of Encryption Keys: Ensure that the encryption keys stored in Zmanda Pro's configuration match those expected by the encryption system of the vault.
Check Storage Vault Settings: Double-check all settings related to the storage vault, particularly those involving data paths and encryption configurations.
Reinitialize Encryption Keys: If mismatches continue, consider reinitializing the storage vault's encryption settings, ensuring all data paths are correctly set.
Error "0xc0000142" in KERNELBASE.dll
This error often indicates a failure in starting a service due to internal Windows errors.
Comprehensive System Update:
Run Windows Update to ensure all system files are up to date.
Check for updates specifically related to .NET Framework and other critical system components.
System File Checker (SFC):
Run
sfc /scannow
to repair corrupted Windows system files.
Event Log Review:
Utilize Windows Event Viewer to identify specific logs that may detail why the error occurred.
Multiple Devices Detected as the Same Device
Issues with device identification can lead to conflicts in device management.
Modify Device Identifiers:
For VMs, change hardware configurations to alter the hardware ID.
On Windows, add or modify the registry key at
HKEY_LOCAL_MACHINE\Software\backup-tool
with a newDeviceIdentificationEntropy
value to force a new device ID.
SSH Key Adjustments:
On Linux and macOS, regenerate SSH host keys to influence device ID generation, using
ssh-keygen -t rsa
and replacing the old keys.
Error "Ciphertext Verification Failed"
This error occurs when encryption verification during a backup or restore operation fails.
Immediate Failure:
This occurs when there is a mismatch between the encryption key in the user's Storage Vault settings and the keys stored within the
/keys/
subdirectory at the data storage location.Initial Setup: On its first use, a Storage Vault generates a unique encryption key that is saved in both the user’s profile and the
/keys/
subdirectory. Consistency between these keys is crucial for access. Mismatches may occur due to:Simultaneous Initializations: If multiple jobs attempt to initialize the same Storage Vault simultaneously, they might overwrite or conflict with each other's key storage, leading to mismatches.
Seed Load Issues: Problems can arise if you are transferring a pre-loaded Storage Vault to a new location without correctly copying all necessary files, or if the setup configuration was not accurately replicated.
Storage Location Reuse: Using the same physical or cloud storage paths for multiple users without unique encryption keys can lead to access issues. Each user or device should have their own distinct Storage Vault, or they should share a single user account setup to maintain consistent encryption keys.
Mid-Job Failure:
Run a deep verification of the storage vault to check for corrupted data chunks.
If corruption is found, consider restoring from a backup or reinitializing the storage vault.
Error: "Not a Supported Backup Storage Location" When Backing Up System State to a USB Flash Drive
The restrictions stem from the underlying wbadmin technology, which does not support USB flash drives as a backup destination due to the risk of the drive being disconnected during the operation.
Microsoft Official Stance: USB flash drives are not supported for system state backups as stated in Microsoft's documentation.
Possible Workarounds:
Modify Drive Properties: Altering the flash drive to simulate a non-removable disk might bypass the restriction. Forum discussions provide methods and tools that can help make this adjustment.
Network Spooling: Setting up a shared network folder on the USB drive and directing Zmanda Pro to treat it as a network path is another strategy. This approach involves configuring the backup system to recognize the drive as part of the network, as detailed in Microsoft's forums.
Factors Contributing to Slow Backup Jobs
Slow backup operations can stem from a variety of sources, ranging from recent system changes to hardware constraints. Here’s a comprehensive breakdown of potential causes and diagnostic steps:
Recent Changes
Software Updates: New software installations can affect the performance of a system. Check the installation dates of software through "Programs and Features" on Windows and correlate these with the onset of backup slowdowns.
Software Updates: Ensure that slowdowns aren't coinciding with recent updates to the Zmanda Pro software itself, which might have altered performance characteristics.
Customer PC Performance
Antivirus Interference: Antivirus programs like ESET NOD32 and Windows Defender scan files on-access, which can slow down backup processes. Configuring exclusions for Zmanda Pro’s executable (backup-tool.exe) might mitigate this. Monitor the antivirus during backups for high resource usage.
Resource Allocation: Adjust Zmanda Pro’s settings to optimize resource usage:
Disable single-thread disk operations.
Remove speed limits set within the application.
Choose between RAM and disk-based temporary storage based on system specifications.
The "Rescan unchanged files" setting can be toggled to potentially improve performance, though it might also lead to increased disk reads.
RAM and CPU Usage
Memory Constraints: Zmanda Pro uses significant RAM for deduplication processes, particularly with large Storage Vaults. Systems with inadequate RAM may resort to using swap files, which degrades performance.
CPU Limitations: Zmanda Pro’s data compression and encryption tasks are CPU-intensive. On systems with weaker CPUs, this can become a bottleneck, especially during peak backup activities.
Storage Performance
Disk Type and Usage: Performance varies significantly between SSDs and HDDs, particularly when multitasks are run on mechanical drives, which might not handle concurrent tasks efficiently.
Network Storage: Backing up from network locations involves considerable data transfer delays. Installing Zmanda Pro directly on the network device hosting the data can improve speed dramatically.
External Drives: The interface of the drive (USB 2.0 vs. USB 3.0) greatly influences the speed. Tools like CrystalDiskMark can benchmark drive performance to anticipate backup speeds.
Windows Performance Mode: For external drives, switching from 'Quick removal' to 'Better performance' in Device Manager can enhance data transfer rates significantly.
Direct Cloud Storage Considerations
Internet Connectivity: Verify both the stability and speed of the internet connection as it is a critical factor when backing up to cloud storage.
Latency Issues: High latency in network connections to cloud or remote storage can lead to prolonged backup times.
Server Health: Regular checks on the Zmanda Pro Server’s CPU and memory usage can help diagnose slowdowns related to server-side processing limits.
Error "mysqldump: Couldn't execute 'SHOW PACKAGE STATUS..."
This error message typically appears when using an incompatible version of mysqldump
with an older MySQL database. Such incompatibilities arise from differences in SQL syntax expectations between versions of MariaDB mysqldump
and the MySQL server being targeted.
Technical Cause: The error is known to occur particularly with mysqldump
from MariaDB 10.3 on Debian Buster 10.0, when it encounters database versions it does not fully support.
Reference for Issue:
Workaround: To circumvent this error, you can disable the backup of stored procedures by modifying the arguments passed to mysqldump
:
Create a Script: Generate a bash script that omits the
--routines
parameter, which is responsible for including stored procedures in the dump.
#!/bin/bash # This program is a wrapper for mysqldump that removes the --routines argument, # to work around issue MDEV-17429 with older MySQL servers args=("$@") for ((i=0; i<"${#args[@]}"; ++i)); do case ${args[i]} in --routines) unset args[i]; break;; esac done /usr/bin/mysqldump "${args[@]}"
Implementation: Store this script at a secure location, for instance,
/opt/ZmandaPro/mysqldump-modified
. Ensure the script is executable:chmod +x /opt/ZmandaPro/mysqldump-modified
.Configuration Adjustment: Modify the backup configuration in Zmanda Pro to utilize this custom script path for MySQL dumps, ensuring that the backup process bypasses the inclusion of routines.
Error "Incorrect function"
This error typically arises when the system encounters a filesystem operation that it cannot execute, possibly indicating disk issues or unsupported commands.
Exploration and Resolution Steps:
File Access Test: Try opening the files in question with conventional software to check their accessibility. This can help determine if the issue is isolated to the backup process.
Disk Health Evaluation:
Access the drive properties through Windows Explorer by right-clicking the affected drive under "This PC".
Navigate to the "Tools" tab and use the "Check" option to perform an error scan.
Error "operation not permitted" on macOS
Background: With macOS 10.14 and later, Apple has enhanced its privacy protocols, requiring apps to obtain explicit permissions from users to access sensitive features or areas of the system, such as the full disk.
Resolution Steps:
Granting Full Disk Access:
Navigate to
System Preferences
from the Apple menu.Go to
Security & Privacy
and select thePrivacy
tab.Scroll down and select
Full Disk Access
.Click the lock icon at the bottom left to make changes, enter your administrator credentials if prompted.
Click the
+
button to add Zmanda Pro (listed under its application name) met Backup if referencing the original software) to the list of applications that have full disk access.Ensure Zmanda Pro is checked to grant it permission.
Zmanda Pro should prompt for these permissions upon first execution or when trying to access restricted areas.
Error "The specified backup storage location has the shadow copy storage on another volume" using Windows System Backup
This error arises when the shadow copy storage configuration conflicts with the wbadmin tool, often related to the configuration of the spool directory.
Troubleshooting Steps:
Verify Spool Drive Configuration: Determine the type of spool drive (e.g., local, network share, SAN). If it's a SAN or managed appliance, specific configurations may need adjustment.
Shadow Storage Check: Run
vssadmin list shadowstorage
in Command Prompt as Administrator to check the shadow copy configuration.
Workaround:
Consider configuring a network share on the same physical drive as the spool directory. Use the UNC path for this network share instead of the direct drive letter, which can help align with the requirements of wbadmin.
Error "Dirty Shutdown" when restoring Exchange EDB content
Issue: After restoring an Exchange Server backup, the EDB file might be in a "dirty shutdown" state, requiring log file merging for accessibility.
Steps to Resolve:
Check Database State:
Use the Exchange utility
eseutil
to check the state:eseutil /MH "D:\restore-edb\File\Mailbox.edb"
Merge Log Files:
Apply necessary log files to the EDB:
eseutil /R E00 /D "D:\restore-edb\File" /L "D:\restore-edb\Logs" /S "D:\restore-edb\Logs"
This process integrates all transaction logs making the database consistent.
Refer to relevant Microsoft documentation for detailed instructions on using eseutil
.
Error "Data error (cyclic redundancy check)" while backing up data
Explanation: This error indicates that Windows encountered a hardware error when trying to read data from a disk, commonly due to bad sectors.
Resolution Method:
Run Disk Check:
Use
chkdsk /f /r
to scan and repair bad sectors. This command might require a system reboot to complete if the target drive is in use.Schedule the disk check for the next system restart if immediate checking isn't possible.
Error "Cannot proceed - Locked by device 'XXXXXXXX'..."
Context: During a backup process, the Zmanda Pro system may temporarily lock a Storage Vault to maintain data integrity while a device completes its backup and runs its retention pass. This lock prevents other devices from writing to the vault during this crucial phase.
Problem Description: The lock file indicates that a device, identified by its unique device ID ('XXXXXXXX'), has secured the Storage Vault. If the device encounters issues such as a power outage or network disconnection, it might leave the vault in a locked state, unable to write new data or complete the current process.
Log File Notification: An entry such as "Locked by device '[deviceID]' (PID #[XXXX]) since [timestamp] (400hrs59m59s ago)" might be observed, signaling a prolonged lock which is unusual.
Resolution Steps:
Identify the Locking Device:
Navigate to: Accounts -> Users -> [username] -> Devices tab -> View.
Enable the 'Device ID' option to see which device is responsible for the lock.
Check Device Status:
Determine if the device is online or has been unexpectedly shut down. If the lock has persisted unusually long, like the noted 400 hours, it suggests the device was shut down or disconnected unexpectedly.
Handling a Persistent Lock:
If the device is offline: Check if it’s due to loss, theft, or destruction. If the device is not recoverable, proceed with unlocking the vault.
If the device is online but the job is stalled: Attempt to cancel the ongoing job via: Accounts -> Users -> [name] -> Actions -> View Job History -> Report. Use the 'Cancel' button if visible.
Best Practice: Always try to wake up or reboot the device if possible before taking further action.
Unlocking the Vault:
Ensure no jobs are running on that Storage Vault.
Access the admin account, enable 'Advanced Options'.
Go to: Accounts -> Users -> [name of user] -> Devices tab -> Actions -> Storage Vault tab -> 'Unlock'. This action removes any stale lock files.
After unlocking, apply retention rules to clean up and prepare the vault for future backups: Accounts -> Users -> [name] -> Devices tab -> Actions -> Storage Vault tab -> 'Apply retention rules now'.
Disable 'Advanced Options' once complete.
Verification:
Review server and job logs to confirm that no errors persist. If issues are insurmountable, contact Zmanda Pro support for further assistance.
Documentation and Strategy Review:
Familiarize yourself with the detailed documentation on handling lock files and consider reviewing backup strategies to prevent future issues related to lock files.
Error "Couldn't determine the size of the Storage Vault"
Overview: Zmanda Pro periodically checks the size of the Storage Vault to monitor data usage. This function supports health checks (such as verifying that the storage size does not unexpectedly shrink during a backup) and helps enforce storage quotas.
Technical Context: Most storage backends, whether they're file systems, SFTP servers, or others, lack a rapid method to gauge the entire size of a directory except by summing the sizes of all contained files. While Zmanda Pro's server caches this size data when calculated, and can provide an outdated figure, obtaining a current measurement is crucial, especially around backup operations.
Issue: If Zmanda Pro encounters issues in accurately measuring the Storage Vault's size, it will log a warning. The backup operation itself will continue, but functionalities relying on accurate size measurements, such as quota enforcement or billing calculations, might be impacted.
Error "A device which does not exist was specified" or "The device is not ready"
Problem: These errors generally indicate issues with the Volume Shadow Copy Service (VSS) during backup operations. They suggest that the VSS snapshot was unexpectedly deleted or became unavailable during the backup process. Common causes include manual deletions (potentially by malware), automatic cleanups by system utilities, or low disk space scenarios that affect the shadow storage space.
Error Details:
Messages like "Open failed because: open ?\GLOBALROOT\Device\HarddiskVolumeShadowCopy16\FOLDER\FOLDER\FILE: A device which does not exist was specified" or "Error for ?\GLOBALROOT\Device\FOLDER\FOLDER\FILE: BackupRead ?\GLOBALROOT\Device\FOLDER\FOLDER\FILE: The device is not ready" highlight that the VSS snapshot was expected but is no longer accessible.
Resolution Steps:
Retry the Backup: Initially, attempt to rerun the backup job. This can help determine if the VSS issue was a transient error or a persistent problem.
Check Disk Space: Insufficient disk space is a common cause for VSS failures. Ensure that there is adequate free space on all volumes involved in the backup, especially where the VSS snapshots are stored.
VSS Admin Tools: Utilize tools like
vssadmin list shadows
andvssadmin list providers
to inspect the current state of VSS snapshots and providers. This can provide insights into whether the snapshots are being created and maintained correctly.System Maintenance Tools: Review any system maintenance tools, including those for cleanup and optimization, that might interfere with VSS. Adjust their settings or operational times to avoid conflicts with backup schedules.
Monitoring and Alerts: Regular monitoring of system logs and backup reports is crucial. Setting up alerts for VSS-related errors can help in early detection and mitigation of issues that could compromise backup integrity.
Error client log shows "Trust evaluate failure: [leaf TemporalValidity]"
Overview: This error pertains to interactions with macOS's Malware Removal Tool (MRT), particularly noted in environments running macOS 10.15.4 Catalina, though it may be prevalent in other versions as well. MRT may interfere with files on externally connected USB storage drives, leading to operational disruptions for Zmanda Pro.
Cause: MRT's function is to quarantine or remove files it deems suspicious, which can inadvertently affect files managed by Zmanda Pro, particularly when these files are located on external drives.
Impact: The arbitrary modification or removal of files by MRT can cause failures in backup processes, manifesting as trust evaluation failures in the client logs.
Recommended Solution:
Avoid External Drives for Critical Data: If possible, opt for storage vaults on local network servers or cloud-based solutions, which are less likely to interact with MRT operations.
System Updates: Ensure that macOS is up to date, as updates may resolve conflicts with external security processes like MRT.
Error client log shows "An imminent failure indicates either bad privileges or WOW64"
Overview: This error typically emerges when Zmanda Pro's client service on Windows lacks the necessary permissions to execute Volume Shadow Copy Service (VSS) snapshots. This is critical for creating consistent backups of files currently in use.
Cause:
Permission Issues: The error suggests that the permissions granted during the installation of Zmanda Pro's client have been overridden, possibly by Windows Group Policy settings, especially in environments where the machine is joined to an Active Directory domain.
WOW64 Interference: This part of the error message suggests issues related to the Windows-on-Windows 64-bit subsystem, which enables running 32-bit applications on 64-bit Windows. It can indicate misconfigurations in how Zmanda Pro interacts with system resources.
Steps to Resolve:
Verify Service Account Permissions:
Open
services.msc
and check the Zmanda Pro service account (typically 'NT SERVICE\backup.delegate').Ensure it has the necessary privileges to manage VSS snapshots.
Check Group Policy Settings:
If the computer is part of an Active Directory domain, verify that domain policies have not restricted the service account's capabilities.
Look for recent changes in Group Policy that might affect backup operations.
Reinstallation:
Reinstall Zmanda Pro's client software to reset its permissions to the defaults required for proper operation.
This action often resolves permission-related issues unless blocked by domain-level policies.
Monitoring and Troubleshooting:
Log Monitoring: Keep an eye on Zmanda Pro's logs immediately following the reinstallation to identify if and when the permissions are modified.
Domain Policy Review: Coordinate with IT administrators to adjust any domain policies that might inadvertently affect backup operations, ensuring that Zmanda Pro's operations are explicitly allowed.
Upgrading Synology NAS DSM (Disk Station manager) software deletes client installed in /opt directory
Affected Systems: All Synology NAS devices that have installed the Zmanda Pro client using the Linux (Other Distribution) installer.
Overview: When upgrading the Synology NAS DSM software, the upgrade process may inadvertently delete third-party applications that are installed in the /opt directory. This directory is commonly used for installing software that isn't part of the standard distribution, but Synology's DSM upgrade process may not fully preserve this directory's contents.
Cause: The DSM upgrade routine on Synology devices is designed to update the system's core functionalities and may not be configured to retain changes or additions in the /opt directory, which is often used for third-party applications like Zmanda Pro.
Solution: To avoid this issue and ensure that the Zmanda Pro client remains intact through DSM upgrades, it is recommended to use the Synology SPK installer. This method packages Zmanda Pro as a Synology package, which is fully supported and managed by DSM, thus ensuring compatibility and persistence across system updates.
Steps to Implement the Solution:
Download the Synology SPK Installer: Starting from Zmanda Pro version 21.12.6, the SPK installer can be downloaded directly from Zmanda Pro's official download page or from a trusted third-party repository.
Install Using Synology Package Center:
Log into your Synology DSM interface.
Navigate to the Package Center.
Select the 'Manual Install' option and upload the downloaded SPK file.
Follow the on-screen instructions to complete the installation, ensuring that Zmanda Pro is installed as a Synology package, which integrates with DSM's native package management system.
Linux client fails to show as new device in user-profile 'Devices' tab
Issue Overview
The Linux client is not visible in the user-profile 'Devices' tab on the Zmanda Pro interface. This problem typically indicates issues with client software operation or network communication.
Potential Causes and Solutions
Software Not Running on the Device
Verification: Use the command
ps aux | grep -i backup
to check if the necessary processes are active. You should see entries like:root <snip> /bin/bash /opt/<name>/backup-daemon-start.sh root <snip> /opt/<name>/backup-tool cmd -ValidateConfig=false -Action=delegate-server root <snip> ./backup-tool stream
Resolution:
If the processes are not running, restart them with:
/opt/BRANDNAME/backup-daemon-start-background.sh &
If restarting doesn't resolve the issue, you may need to reinstall the client software.
Communication Issues with the Server
Test Communication: Simulate a server login from the Linux client using the following command:
curl -v -X POST --data-urlencode "Username=<username>" --data-urlencode "AuthType=Password" --data-urlencode "Password=<password>" <yourURL>/api/v1/user/web/session/start
A successful response will confirm server accessibility.
Check Network Settings:
Ensure there are no network issues blocking communication.
Verify that the Zmanda Pro server firewall allows incoming communications on the necessary ports.
Documentation for Setup: Refer to Zmanda Pro Linux Client Installation for detailed setup instructions.
Linux client only shows as 'Offline' in user-profile 'Devices' tab
Issue Overview
After initial registration, the Linux client may appear as 'offline' in the user-profile 'Devices' tab within Zmanda Pro, indicating connectivity or operational issues.
Potential Causes and Solutions
Software Not Running on the Device
Verification: Execute the command
ps aux | grep -i backup
in the terminal to check for active backup processes. You should expect to see:
root <snip> /bin/bash /opt/<brand_name>/backup-daemon-start.sh root <snip> /opt/<brand_name>/backup-tool cmd -ValidateConfig=false -Action=delegate-server root <snip> ./backup-tool stream
Resolution:
If these processes are not active, initiate them using:
/opt/BRANDNAME/backup-daemon-start-background.sh &
If restarting the processes does not resolve the issue, consider reinstalling the client software to ensure proper installation and configuration.
Communication Issues with Zmanda Pro Server Test Server Communication: Simulate a server login from the Linux client using this CURL command, replacing placeholders appropriately:
curl -v -X POST --data-urlencode "Username=<username>" --data-urlencode "AuthType=Password" --data-urlencode "Password=<password>" <yourURL>/api/v1/user/web/session/start
Successful output should look like:
{"SessionKey":"abc1fd20-7177-12362-88ba-863efgfe07b0","SessionType":"user","Status":200,"Message":"Logged in OK."}
Troubleshooting:
Ensure the client's network configuration allows communication with the Zmanda Pro server.
Verify firewall settings on Zmanda Pro server to ensure they permit incoming connections on the necessary ports.
Ensuring Persistent Operation
Ensure Automatic Start: Verify that the client software is configured to start automatically at boot by following instructions from Zmanda Pro Documentation on Linux Client Setup.
Linux Client Uninstallation and Reinstallation
Uninstallation:
Stop all related processes:
ps aux | grep -i backup sudo kill -9 <pid>
Remove the installation directory:
rm -rf /opt/BRANDNAME/
Reinstallation:
Follow detailed installation instructions available at Zmanda Pro Linux Client Installation to ensure the client is set up correctly after uninstallation.
Note
All steps provided ensure the Zmanda Pro Linux client operates efficiently and remains visible as 'online' within the user-profile 'Devices' tab. Comprehensive setup and troubleshooting steps can be found in the detailed Zmanda Pro documentation linked throughout the solution sections.
Commands Executed Before or After a Backup Don't Run
Problem Overview:
Commands intended to run before or after a backup operation in Zmanda Pro may fail to execute due to insufficient permissions or incorrect settings.
Possible Causes and Solutions:
Command Access and Permissions:
Ensure the command or batch file is located in a directory accessible by the Zmanda Pro client software. Verify the command file has the necessary execution permissions.
Adjust permissions for the client service:
Utilize
services.msc
to modify thebackup.delegate
service to "log on as" LOCAL SYSTEM.Alternatively, enhance permissions for the NT SERVICE\backup.delegate user account. Detailed instructions on setting permissions for Windows services can be found at: Setting Permissions on Windows Service.
Cautionary Note:
It is recommended to grant only essential permissions to the Zmanda Pro client to minimize security risks. Avoid using elevated privileges as a default solution.
Windows Client Does Not Show as New Device in User-Profile 'Devices' Tab
Problem Overview:
After installation, the Windows client fails to appear in the user-profile 'Devices' tab in Zmanda Pro.
Causes and Checks:
Software Not Running:
Verify the client widget is active in the system tray.
If the client is running, ensure it is logged in with the correct user-profile credentials.
If the client is not active, start the program from the 'Start' menu or consider reinstallation if it fails to launch.
Communication with Zmanda Pro Server:
Test server connectivity using the following CURL command from the Windows client (requires Windows 1809 or later, or CURL installation from CURL for Windows):
curl -v -X POST --data-urlencode "Username=<username>" --data-urlencode "AuthType=Password" --data-urlencode "Password=<password>" <yourURL>/api/v1/user/web/session/start
Successful API connection will return:
{"SessionKey":"abc1fd20-7177-12362-88ba-863efgfe07b0","SessionType":"user","Status":200,"Message":"Logged in OK."}
Check network settings and ensure the Zmanda Pro server firewall allows incoming communications on the designated ports.
Windows Client Shows as 'Offline' in User-Profile 'Devices' Tab
Problem Overview:
The client software has registered as a new device but now displays as 'offline' in the user-profile.
Causes and Checks:
Software Not Running:
Ensure the client widget is active in the system tray. If not, start the program from the 'Start' menu.
If the client does not run, check for interference from local antivirus programs or consider reinstallation.
Communication with Zmanda Pro Server:
Validate connectivity with the Zmanda Pro server using the same CURL command as mentioned above to ensure the client can reach and interact with the server.
Note: Ensure all configurations and troubleshooting steps are in accordance with the Zmanda Pro documentation and security policies.
Job Log Message "Couldn't Determine the Size of the Storage Vault"
Problem Overview: This warning message occurs when the backup software times out waiting for the storage location to count and supply the size of the Storage Vault. This is particularly common when using TrueNAS storage solutions with a server operating on Linux.
Solution: To resolve this issue and speed up the size determination process, follow these steps:
Mount the TrueNAS Storage on the Server:
Use CIFS/SMB to mount the TrueNAS storage directly to the server.
Change Storage Settings:
Configure the server to use a local folder for storage instead of a network path.
This adjustment allows the software to quickly determine the storage size, nearly instantaneously.
Error Message "Failed to Browse Local Disks" When Adding Disk Image Protected Item Using Desktop Client
Problem Overview: This error occurs when the software cannot access certain disk partitions during the setup of a Disk Image Protected Item.
Solution:
Check Disk Management:
Use Windows 'diskmgmt.msc' to check for any virtual disks that are set to 'offline'.
Change the disks to 'online' status to resolve the issue.
Missed Backup Job Fails to Start
Problem Overview: Missed backup jobs fail to start even if the option 'When PC Starts, if Last Job was Missed' is selected, especially on devices like laptops that might go into sleep mode.
Causes and Solutions:
Device Suspension:
Laptops that go into sleep mode suspend all processes, causing scheduled backups to miss their designated start times.
Rescheduling the Backup:
Reschedule the backup for times when the device is likely to be awake and online.
Alternatively, set the device to remain on or only lock the screen instead of entering sleep mode.
Job History Shows a Series of 'Missed' Backups
Problem Overview: The job history may display a series of 'Missed' backups, occasionally followed by 'Successful' ones.
Causes and Solutions:
Time Synchronization:
Ensure that both the server and the device are synchronized with internet time to avoid time drifts that can cause backups to miss their schedules.
Check for Simultaneous Schedules:
Review the backup schedule for any configurations that might set simultaneous backups for the same Protected Item.
Job Log Shows Warning Regarding Sync Errors
Problem Overview: This warning occurs when the sync function detects that data has not been fully written to a disk, especially common with USB storage.
Solution:
Change Storage Type:
Use a storage type that fully supports the sync functionality, such as internal or NAS drives, instead of USB sticks.
Error Log Shows "BucketExists: Get https://{server}/{bucket}/?location=: dial tcp: lookup {server}: no such host"
Problem Overview: This error occurs when trying to add a new Storage Vault or perform a backup to a cloud storage location and the device cannot resolve the server's hostname.
Steps to Resolve:
Device and Network Checks:
Verify if the problem persists across different devices using the same user credentials.
If isolated to one device, use an S3-Compatible client like CyberDuck to manually verify the connection to the storage bucket.
Network Environment Check:
Ensure that the network allows connections to the storage server, especially in restricted environments like corporate networks.
SSL and Time Synchronization:
Update the device's SSL certificates and synchronize its clock with internet time to ensure proper communication.
Unexpected Backup Jobs Running
Problem Overview: Backup jobs are appearing in the job logs at times when they are not scheduled.
Possible Causes:
Misconfiguration: Settings within the backup configuration may be incorrectly set, leading to backups running at unintended times.
Time Zone Issues: Incorrect time zone settings on the server or the client device can cause schedules to execute at the wrong time.
Device Behavior: Devices that reboot or experience intermittent network connections may trigger backup jobs upon reconnection or startup.
Solutions:
Reviewing Detailed Job Logs:
Access the detailed job logs to identify what triggered the backup job. Logs will include the specific rule that initiated the backup and a description that can help diagnose why the backup occurred outside its scheduled time.
Scheduled Backup Checks:
Verify the scheduled backup settings in the backup application. Ensure all schedules are set correctly according to the desired times and time zones.
Adjust any backup schedules that may be configured incorrectly.
Handling Missed Scheduled Backups:
Check settings related to missed backups. Some systems may be configured to automatically run a backup at the next opportunity if a scheduled backup was missed due to the device being off or disconnected.
Adjust these settings if they are causing unintended backup jobs.
Managing Device Startup Behavior:
Investigate if backups are set to trigger on device startup. This setting can cause unexpected backups if the device frequently restarts or reconnects to the network.
Consider disabling automatic backups on startup if this feature is not needed, or configure it to better suit your operational environment.
Network Stability Improvements:
Ensure that the network connection between the client devices and the backup server is stable. Intermittent connectivity issues can cause unexpected backup behaviors.
Configure network equipment to provide reliable connectivity to prevent devices from losing connection to the backup server.
Last updated