How to troubleshoot common issues in Zmanda Disaster Recovery service

This article explores common scenarios that can lead to failures in Zmanda’s Disaster Recovery (DR) functionalities. This is for Zmanda Version 5.1. It’s divided into two sections:

Section 1: DR sync failure scenarios

This section explores various situations that can lead to DR sync failures, topics covered include:

• DR repository not configured

• Unreachable DR repository

• License issues

• Health check failure

• Non-primary current host

Section 2: DR service – restore flows failure scenarios

This section delves into potential causes of failures during the DR restore process, topics covered include:

• Improper installation

• Expired license

• Missing file

• Import command failures

• Network issues

• Security of the storage

• Power outage during restore

DR sync failure scenarios

Scenario 1: DR repository not configured

If the DR repository hasn’t been configured, Zmanda doesn’t know where to store server backups, leading to DR sync failure.

To fix this issue, you need to configure the DR Repository where Zmanda will store your server backups.

Scenario 2: Unreachable DR repository

Even with a configured DR repository, the following issues can prevent Zmanda from accessing it:

• Network issues: Disconnected cables, Wi-Fi drops, or firewall/router problems can cause connection problems.

• Firewall/antivirus blocking: Firewalls or antivirus software on either side may block traffic. Check ports 137-139 and 445 are open.

• Account blocking policies: Repeated failed login attempts can result in account lockouts.

• Missing DR repository: The configured DR repository might have been moved or deleted. Verify its presence and availability.

Specific to SMB storage:

• Name resolution problems: Issues with DNS or NetBIOS resolution can prevent connection establishment.

• Incorrect share path: Ensure the path to the shared resource is correct. Typos or incorrect paths can lead to failures.

• Permissions and share settings: User accounts need proper permissions on the shared resource. Misconfigured share settings can also cause failures.

• Incorrect credentials: Incorrect credentials for the configured SMB will prevent connection.

Scenario 3: License issues

• An active license is required for all Zmanda operations, including Disaster Recovery. Without a valid license, DR won’t take backups and DR sync will fail.

• If the license has expired, DR sync will be terminated immediately.

Scenario 4: Health check failure

DR service checks the health of servers before backups. If the health check fails, DR sync is terminated. This indicates potential server issues.

Zmanda employs an exponential retry mechanism when it encounters a failed health check. This means it will attempt to retrieve the server’s information multiple times with increasingly longer intervals between retries. However, if the server remains unresponsive or inaccessible after four attempts, Zmanda will ultimately terminate the DR sync process.

Scenario 5: Non-primary current host

DR service only backs up the primary server. In cases where DR restore operations are performed on the secondary server and automatic switching to the primary server from the secondary fails during DR restore operations, DR sync may fail.

DR service – restore flows failure scenarios

This section covers issues that can lead to DR restore failures.

Scenario 1: Improper installation

Check the status of Zmanda components:

setup-zmc

setup-aee

setup-dedup-server

Make sure all components are running.

Scenario 2: Expired license

An active license is required for restoration on the secondary server. Renew your license if your license is expired from Welcome to the Zmanda Network.

Scenario 3: Missing file

The /var/lib/amanda/drservice/drconfig file is crucial for the restore process. Copying this file to the secondary server allows the DR service to establish a connection with the backup repository, ensuring successful restoration of data. Without this file, the DR service wouldn’t be able to locate and access the stored backups on the secondary server.

Scenario 4: Import command failures

• The /opt/zmanda/amanda/bin/drservice import –sources <path-to-drconfig-on-secondary> command must be executed on the secondary server to activate the DR instance.

• Ensure the drconfig file has read permissions for the amandabackup user with these commands:

chown amandabackup: <path-to-drconfig-on-secondary>
chmod 644 <path-to-drconfig-on-secondary>

Scenario 5: Network issues

Even with a configured DR repository, the following issues can prevent Zmanda from accessing it:

• Network issues: Disconnected cables, Wi-Fi drops, or firewall/router problems can cause connection problems.

• Firewall/antivirus blocking: Firewalls or antivirus software on either side may block traffic. Check ports 137-139 and 445 are open.

• Account blocking policies: Repeated failed login attempts can result in account lockouts.

• Missing DR repository: The configured DR repository might have been moved or deleted. Verify its presence and availability.

Scenario 6: Security of the storage

• Name resolution problems: Issues with DNS or NetBIOS resolution can prevent connection establishment.

• Incorrect share path: Ensure the path to the shared resource is correct. Typos or incorrect paths can lead to failures.

• Permissions and share settings: User accounts need proper permissions on the shared resource. Misconfigured share settings can also cause failures.

• Incorrect credentials: Incorrect credentials for the configured SMB will prevent connection.

Scenario 7: Power Outage During Restore

Ensure machines don’t experience power outages during the restore process, as it can leave Zmanda in an inconsistent state.

sudo systemctl restart __sub-zman-dr

With this article, you should be able to troubleshoot DR sync failures and DR restore failures. If you have any further questions, reach out to our sales team.