Skip to main content


Druva Documentation

Troubleshoot common scenarios

Phoenix Editions: File:/cross.pngBusiness         File:/tick.png Enterprise     File:/tick.pngElite
(Purchase Separately)

This topic lists the scenarios that you might encounter while executing Phoenix DRaaS. For more information about troubleshooting Virtual Machine Import/Export errors, see Troubleshooting VM Import/Export.

Disaster recovery fails, if any of the disks of the virtual machine is not mounted.

Resolution: Ensure that you mount or detach the unmounted disks.

Disaster recovery fails, if the virtual machine is part of the domain. The domain is configured during the virtual machine creation from the VMware console. The disaster recovery behavior depends on the availability of the corresponding domain on AWS.

Resolution: Ensure that you assign a virtual machine to a workgroup to be able to perform disaster recovery.

The failover EC2 instance may not show some disks and their contents.


  1. Log into the EC2 instance.
  2. Run the following command to list all the block devices:

    fdisk -l

    This command lists all the block devices with their size and other details.

    Consider a 64 GB disk whose content was not visible post failover as shown in the following output:

    Disk /dev/sda: 42.9 GB, 42949672960 bytes, 83886080 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk label type: dos
    Disk identifier: 0x000b6fff

    Device Boot         Start         End      Blocks   Id   System
    /dev/sda1   *        2048    60448767    30223360   83   Linux
    /dev/sda2        60448768    83886079    11718656   82   Linux swap / Solaris

    Disk /dev/sdb: 1649.3 GB, 1649267441664 bytes, 3221225472 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes

    Disk /dev/sdc: 64.4 GB, 64424509440 bytes, 125829120 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk label type: dos
    Disk identifier: 0x000be2b0

    Device Boot      Start         End      Blocks   Id  System
    /dev/sdc1            2048   125829119    62913536   83  Linux

  3. Check the block device name of the disk whose contents are not visible.
  4. Ensure that all the entries in the /etc/fstab file refer to the block device names as shown in the output of step 2. For example, the /etc/fstab file should have the following entry:
    [root@BackupProxy ~]# cat /etc/fstab

    # /etc/fstab
    # Created by anaconda on Fri Jan 20 17:48:45 2017
    # Accessible filesystems, by reference, are maintained under '/dev/disk'
    # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
    UUID=7f822040-5b0f-4a8c-b587-6abde319fd2b /                       ext4    defaults        1 1
    /dev/sdc1 /var                    ext4    defaults        1 2
    UUID=1c129f59-7b86-4b2c-b33e-175c65b672f1 swap                    swap    defaults        0 0

    The entry in the bold needs to be verified against the fdisk output.

How to resolve the post-boot script errors

Resolution: To resolve any post-boot scripts, perform the following steps:

  1. On the Phoenix Management Console, go to the Jobs page and click the Disaster Recovery tab.
  2. Click the Job ID of the corresponding DR failover job for which you want to view the error details.
    The Job Details page appears.
  3. In the Summary tab, the Error code field displays the code of the error along with a link to the documentation for more details.
  4. Click the Recovery Workflow tab, and analyze the virtual machines for errors.
  5. Click the Detailed Logs tab and click Download Job Logs to download the log files containing errors for that job.
    The PhoenixLogs-<JobID>.zip is downloaded.
  6. Navigate to the PhoenixLogs-<JobID>/failover/<number>/Phoenix.<timestamp>-<JobID>.zip/Phoenix-TW-<timestamp>-<JobID> folder. It contains the following two files:
    • stderr.log: Contains the detailed error message of the script failure.
    • stdout.log: Contains the execution log of the script.
  7. Resolve the error and execute the recovery workflow again.