Skip to main content
Druva Documentation

Quick reference guide to Phoenix deployment

 If you are new to Phoenix and want to understand the how-to's of Phoenix deployment, this guide will help you get started. 

Phoenix deployment workflow

  1. Phoenix concepts related to deployment 
  2. Initial configuration for deployment
  3. Deploy Phoenix to back up Windows or Linux server data/VMware virtual machines/Hyper-V virtual machines/NAS Share data/Oracle databases
  4. Configure CloudCache (optional)
  5. Configure disaster recovery plan for VMware (optional)
  6. Monitor backup, restore, and disaster recovery activities

Note: Ensure that you have the valid licenses. For more information, see License consideration

Phoenix concepts related to deployment 

Before you deploy Phoenix, get acquainted with the following key concepts:

Storage

Phoenix stores data backed up from different servers in Phoenix Cloud. You can pre-purchase Phoenix storage using credits depending on the data needs and location preferences, and in-effect pay only for the storage that you consume. The purchased storage is translated into credit allocation. For example, if you have purchased a 10-TB Phoenix storage for a contract term of one year, 120 credits (TB months) are allocated to your account.

You can effectively track the purchased credits and storage consumption using Dashboard. For more information about credit usage, see Phoenix credits

Organizations

An organization is an access-based control mechanism to configure servers for backup and restore. Organizations create a logical partitioning of the entities, such as servers, backup policies, and so on. Servers and policies in one organization cannot be accessed by another organization. An organization administrator is assigned to each organization. The organization administrator has complete control only over the assigned organization and not over other organizations.

Phoenix provides a default organization to configure servers in your environment. You can also add a new organization based on the data requirements. For more information about the organization, see Organizations.

Administrative groups

Administrative groups provide a logical categorization of servers based on common characteristics, such as operating systems, administrators, and so on.  An administrative group allows you to organize servers for better management. To manage the servers under a group, you assign a group administrator. For more information about server groups, see Administrative groups.

Phoenix Administrators 

  • Cloud administrators perform activities, such as configuring, managing, and monitoring the Phoenix setup.
  • Organization administrators manage one or more organizations assigned by cloud administrator. Organization administrators create and manage group administrators for the assigned organizations.
  • Group administrators manage administrative group-related activities such as managing servers belonging to the administrative groups. 
  • Cloud administrators (View only) manage audit trails and reports for all organizations and view the activities of all the organizations.
  • Organization administrators (View only) manage the reports and view the activities of the organization(s) they have access to.
  • Group administrators (View only) view the activities of the administrative groups they are associated with.
  • Data Protection Officer (DPO) manage the audit trail and reports,  and the backup and restore tasks. They can also configure the disaster recovery plan and trigger failover.

Backup policy

Backup policy is a set of rules to back up your physical and virtual servers as per the data requirements. The rules include the backup schedule, the backup frequency, the workload-specific backup settings, and how long do you want to retain the backed-up data for a server. Phoenix uses the Grandfather–Father–Son (GFS) retention method for maintaining hierarchical restore points. For more information about the backup policy, see Backup policy.

CloudCache

Phoenix CloudCache is a software application installed on Windows server. For the supported version of Windows server, see Support matrix.

CloudCache temporarily stores the backed-up data from Phoenix agents, and then periodically syncs data with Phoenix Cloud. You can use CloudCache to back up a large volume of initial data, accelerate or optimize the backup process, perform faster restores, and optimize your network bandwidth consumption. For more information about CloudCache deployment, see Phoenix CloudCache deployment process workflow.

Disaster recovery plan

Disaster recovery plan is a set of rules for recovering the data in case of emergency or disaster. In a disaster recovery plan, you configure your AWS account and a schedule to create EBS snapshots from Phoenix storage to the AWS account. For more information, see About disaster recovery plan.

Initial configuration for deployment

Phoenix account login

Log on to the Phoenix Cloud. Phoenix provides a centralized management console to manage all your configurations and administration of the server-side and the client-side resources. 

Add a new organization

Based on the requirements, add one or more organizations, or use the default organization to configure servers in your environment.

org_new.png

 

Create administrator accounts and roles

Create cloud administrators, organization administrators, and group administrators to perform the Phoenix tasks.

Manage_admin.png

 

Configure single sign-on for Phoenix

Single sign-on is a mechanism that allows users to access multiple resources using a single action of authentication and authorization. If you are planning to use single sign-on for Phoenix administrators, configure single sign-on.

Related articles:

Configure Windows/Linux servers

Configure the servers for backup and restore. This step provides information about File servers and MS-SQL servers. For information about configuring VMware setup, click here.

Register servers

To enable data backup from your physical servers, you must register the servers with Phoenix. 

The complete server registration process consists of the following steps:

  1. Install the Phoenix agent
  2. Generate the activation token
  3. Activate the registered server

Install the Phoenix agent

Phoenix agent is the client component that you need to install and activate on each server that you want to backup and restore. The Phoenix agent communicates with the Phoenix Cloud. For more information on installing and activating the agent, see Install the agent and register a server

The Phoenix agent installer is available at http://downloads.druva.com/phoenix/.

Generate the activation token

When you are registering a server, you can generate an activation token and use that activation token to register the server. You can generate a single token to register multiple servers.

Activate the registered server

Use the activation token to activate your registered servers installed with the Phoenix agent.

Activation ensures that Phoenix agents establish a persistent connection with Phoenix Cloud to enable backups from the servers on which the agents are installed.

FS_SQL_activation_token.PNG

Create administrative group

Create appropriate administrative groups for servers to enable better management of the servers. For more information about creating administrative groups, see Add an administrative group.

Create_Administrative_Group.JPG

Create backup set

Create a backup set to define the workload type, the content to back up, the storage for the backed up data (snapshots), and schedule to back up the data.

The content rule or custom content in a backup set specifies what data should be backed up. When you create a content rule for File servers, you choose file types and folders. By default, Phoenix provides a content rule that already includes certain file types and folders that you can use. In addition, you can create a custom content, and save it with a name so that you can use it later in other backup sets that you create. When you define the backup content for MS-SQL servers, you specify the databases that you want to backup.

File_backup_content_rule_Mixed_Workload.PNG

The backup policy in a backup set specifies when a backup job is executed for a server, the bandwidth available to the agent, and for how long to retain a snapshot or log backup. 

Create_new_backup_policy_schedule.JPG

Phoenix also allows you to back up servers that run mixed workloads of the File server and MS-SQL server. You can configure multiple dataset backups of the File server and MS-SQL server on a single server. The backup sets can be independently configured, backed up, restored, and mapped to a storage or a CloudCache. For more information about how to configure servers with the mixed workload, see Configure registered servers for mixed workload backup.

Related articles:

Configure a VMware setup

Register the VMware setup, deploy backup proxy, and configure a virtual machine for backup and restore. Phoenix supports the following versions of VMware infrastructure:

  • Standalone ESXi
  • Geographically-distributed ESXi hosts managed by single vCenter server

Register VMware setup

To enable data backup from the VMware setup, you must register the VMware setup with Phoenix. 

The complete VMware setup registration process consists of the following steps:

Backup proxy setup

Set up the backup proxy to back up virtual machines from the VMware setup. Backup proxy setup includes the deployment of the OVF template on your hypervisor. You can download the backup proxy at the time of generating activation token or from the downloads page.

Generate activation token

When you are registering a VMware setup, you can generate an activation token and use that activation token to establish the connection between backup proxy and Phoenix. You can generate a single token to activate multiple backup proxies.

Copy the activation token that is generated.

Deploy backup proxy for VMware

Use the OVF template that you have downloaded while registering VMware setup and deploy it either on standalone ESXi or central vCenter server.

  • Deploy backup proxy on vCenter

Log on to your vCenter Server using vSphere Client and then use the Deploy OVF Template option to deploy and configure a backup proxy. Activate the backup proxy at the time of configuration. Activation ensures that backup proxies establish a persistent connection with Phoenix Cloud, thereby, enabling backups from the virtual machines on which backup proxies are installed.

  • Deploy backup proxy on standalone ESXiESXi

For standalone ESXi servers, deploying and configuring backup proxy are two separate processes.

  1. Log on to your ESXi using vSphere Client and use the Deploy OVF Template option to deploy backup proxy.
  2. Log on to each ESXi server and start the backup proxy application.
  3. Follow the screen prompts and specify the valid information.
  4. Activate the backup proxy at the time of configuration. Activation ensures that backup proxies establish a persistent connection with Phoenix Cloud, thereby enabling backups from the virtual machines on which backup proxies are installed.

Create a new backup proxy pool

Backup proxy pool is a collection of backup proxy servers. The backup proxy pool eliminates the need to manually map virtual machines to an individual backup proxy server. All backup requests from the virtual machines are assigned to the backup proxy servers from the mapped backup proxy pool based on the load balancing mechanism.

For geographically distributed ESXi servers managed by single vCenter, create one backup proxy pool per geographic organization or remote location. Add the backup proxies deployed locally in that organization or location to the backup proxy pool. Assign the backup proxy pool to virtual machines locally present in that geographic organization. For example, an XYZ company has the main organization in Switzerland and three remote locations, one each in Singapore, Germany, and China. At each location, an ESXi host is deployed that manages different virtual machines implemented at that location. A vCenter server is deployed at the main organization in Switzerland, which manages the ESXi host at each remote location.

To efficiently perform backup and restore activities, we recommend you to deploy backup proxy at each remote location. Create a backup proxy pool at each organization and add the locally deployed backup proxy to the respective backup proxy pool. Finally, assign this backup proxy pool to the virtual machines locally present at each location.

For a data center, a single backup proxy pool is sufficient. However, you can create multiple backup proxy pools if you want to assign dedicated backup proxy resources to certain virtual machines.

Add new backup proxy to the pool

After creating the backup proxy pool, you can add the backup proxies to that pool so that these backup proxies can handle the backup and restore jobs for various virtual machines.

Assign the backup proxy pool

When configuring the virtual machines, you must assign the virtual machine to the backup proxy pool. The backup proxy from the assigned backup proxy pool performs the backup of all VMDK and VMX files from this virtual machine.

Configure virtual machine for backup

In Phoenix, you can configure:

  • A single virtual machine for scheduled backup.
  • A single group of virtual machines so that they share a backup schedule.
  • Multiple groups of virtual machines such that each group shares a backup schedule.

The configuration of a virtual machine for backup is a simple, two-steps process. Open the Configure VM for Backup wizard and follow the prompts.

  1. Under the Backup Settings tab, select the storage, administrative group, and backup policy.
  2. Select the backup proxy pool. 

Related articles:

Configure Phoenix to backup and restore Hyper-V virtual machines

Register your Hyper-V host, install the agent, and configure virtual machines for backup. Phoenix supports virtual machine backup for virtual machines on:

  • Standalone hosts
  • Hyper-V clusters
  • Hosts managed using SCVMM

The following sections describe the steps required to backup and restore virtual machines.

Register a Hyper-V host

To backup and restore the virtual machine, register the Hyper-V host. The Phoenix agent registers the host with Phoenix and detects the virtual machines running on the host. 

Registration includes the following steps:

  • Download the agent
  • Generate activation token
  • Install and activate the agent

Download the agent

You can download the agent from this page.  In addition, Phoenix lets you download the agent at the time token generation.

Generate activation token

You generate an activation token using the register button which is available when you select your organization and then select what you want to back up. To generate an activation token, login to Phoenix management console > select your organization > VMs > Hyper-V. When you see the Hyper-V page, click Register New Setup. The Register Server wizard appears.

hyper-v2.png

Follow the instructions on the wizard to generate a token. 

Activate the agent

Install the agent on the host, and run the following command:


PhoenixHyperVControl.exe activate <activation_token> --type <scvmm/cluster/standalone> --scvmm_fqdn <scvmm FQDN> --user <scvmm/cluster username> --password <scvmm/cluster password>

For detailed instructions on how to register a host, see  Register a Hyper-V host.

Configure virtual machines for backup 

After a Hyper-V host is registered, the host is listed on the Phoenix Management Console using its hostname. To see your Hyper-V host listed, select your organization on the Phoenix Management Console > VMs > Hyper-V. 

On the Hyper-V page, you can see all the virtual machines running on registered hosts. Select the virtual machines you want to configure and click Configure VM for Backup. The Configure VM for Backup wizard appears. Follow the instructions on the wizard to configure virtual machines. For detailed information, see Configure Virtual Machines For Backup.

Related articles:

Configure Phoenix to back up and restore NAS Shares

Configure Phoenix to back up and restore NAS Shares in the following steps:

  1. Add and activate a NAS Proxy
  2. Add a NAS device
  3. Add a NAS Share
  4. Map NAS Proxy to a NAS device
  5. Configure backup set for NAS Share

Add and activate a NAS Proxy

NAS Proxy is the Phoenix Agent that handles backup and restore requests from NAS Shares. To back up from SMB type NAS Shares, you must install the NAS Proxy on a Windows server. Similarly, if your NAS Shares are of NFS type, you need to install the NAS Proxy on a Linux server. 

To add and activate a NAS Proxy, you must:

  1. Add a proxy on Phoenix Management Console and generate an activation token.
  2. Install and activate the proxy on a Windows or Linux serve

Add a proxy on Phoenix Management Console and generate an activation token

  1. Log in to Phoenix Management Console.
  2. On the menu bar, click All Organizations and select the organization to which you can add the NAS device.
  3. On the menu bar, click Protect > NAS
  4. On the NAS page click Add NAS Proxy
  5. Click Next under Install Druva Phoenix Agent on the Add NAS Proxy page.

    InstallPhoenixAgent.png

    The Click here link opens the web page from where you can download the NAS Proxy installer. Download the Phoenix Agent installer, as it is NAS Proxy is the same as the Phoenix Agent.  
  6. Under Generate Activation Token, provide the following details and click Next.

    GenActivToken.png
     
    Field Description
    Token Description
    (Mandatory field)
    A short description of the activation token. 

    This token can activate

    The number of servers that the activation token can activate.

    Default value: 25

    The token expires in

    The number of days after which the activation token expires.

    Default value: 7

  7. Under Activation, click copy and save the activation token in a text file. Use this token to activate the NAS Proxy that you install on the Windows or Linux server.

    NASToken.png
    Note:The server on which you install the proxy does not store activation token. Therefore you must copy the activation token to a text file.
  8. Click Finish

Keep the text file or the activation token, generated through the above procedure, handy when you activate the NAS Proxy

Install and activate the proxy on a Windows or Linux server 

To install the proxy on a Windows server:

  1. Go to the location where you have downloaded the NAS Proxy installer.
  2. Double-click the NAS Proxy installer.
  3. Click Next
  4. In the Install location box, type or select the full path to the installation home directory. 
  5. Click Install.
  6. After the installation completes, click Finish.

To activate the NAS Proxy on Windows server:

  1. Keep the text file containing the activation token handy.
  2. Open the command prompt window and navigate to the location where the NAS Proxy .msi file is installed.
    Typically the location is C:\Program Files\Druva\Phoenix Agent.
  • For Phoenix Cloud: PhoenixNasControl.exe activate <token> 
  • For GovCloud: PhoenixNasControl.exe govcloud activate <token> 

 In both the above commands, <token> is the activation token and <ServerName> is the name you give to the Windows server that will run the NAS Proxy. 

  To install the NAS Proxy on RHEL, CentOS, or SLES:

  1.  Go to the directory that contains the NAS Proxy installer.
  2. Run the command:
    rpm –ivh <package name>
    Where <package name> is the installer name with its extension.

To install the NAS Proxy on Ubuntu:

  1. Go to the directory that contains the NAS Proxy installer.
  2. Run the command:
    dpkg –i <package name>
    Where <package name> is the installer name with its extension.

To activate the NAS Proxy on Linux server:

  1. Open the command prompt.
  2. Go to opt/Druva/Phoenix/lib directory.
  3. Run the following command:
  • For Public Cloud: PhoenixNasActivate activate <token>
  • For GovCloud: PhoenixNasActivate govcloud activate <token>

 In both the above commands, <token> is the activation token and <ServerName> is the name you give to the Windows server that will run the NAS Proxy.

Add a NAS device

Add the NAS device from which you want to back up data.

  1. Log in to Phoenix Management Console.
  2. Click the All Organizations list and select the required organization.
  3. On the menu bar, click Protect > NAS. The NAS page is displayed, with the NAS Devices and NAS Proxies tabs.
  4. On the NAS Devices tab, click Add New NAS Device. This displays the Add New NAS Devices window, with NAS Details and NAS Proxy Mapping tabs.
  5. Under NAS Details tab, enter the NAS device details as described in the table below and then click Next.
  6. Under NAS Proxy Mapping tab, select one or more NAS Proxies that you want to map to the NAS device. If there is an error in the proxy mapping, an error message is displayed. You can also map the proxy later. 

    NASProxyMapping.png
     
  7. Click Finish. The NAS device name appears on the NAS Devices tab.
    After adding the NAS device, you can add its shares on Phoenix Management Console. Although Phoenix allows you to add any number of devices,  shares, and proxies, you must map the proxies to the NAS device for Phoenix to establish connectivity with the device shares.

Add a NAS Share

  1. Log on to Phoenix Management Console.
  2. Click the All Organizations list and select the organization with registered NAS devices.
  3. Click Protect > NAS.
  4. Click the NAS device in which you want to add a NAS Share. The server page opens with Shares and NAS Proxies tabs.
  5. On the Shares tab, click Add New Share. The Add New Share window is displayed.

    AddNewShareWindow.png
     
  6. Enter details as described in the table below and then click Add Share.
     
    Field  Description
    Share Name Path to NAS Share on the NAS device.
    Credentials
    Use NAS credentials Allows access to NAS Share using the access credentials of the NAS device. Phoenix validates the NAS device credentials when you add a share using this option. 
    Username Access credentials of the NAS Share.
    Password

    Share Type

     

    • Select SMB if the NAS Share is running on Windows
    • Select NFS if the NAS Share is running on Linux

    Phoenix does not support backup and restore from mixed share types.

    Administrative Group Assign the administrative group under which you want the NAS Share to appear. You can also create a new administrative group if the NAS Share does not fit in the existing groups. See Manage administrative groups for NAS Shares for steps to create an administrative group.

    Phoenix Management Console displays the newly added NAS Share on the NAS device details page.  You can use this procedure to add more NAS shares. 

Map NAS Proxy to a NAS device

  1. Log on to Phoenix Management Console.
  2. On the menu bar, click All Organizations and select the organization to which you can add the NAS device.
  3. On the menu bar, click Protect > NAS. The default NAS page appears with the list of NAS devices.
  4. Click the NAS device name to which you want to map the NAS Proxy. The NAS device details page opens.
  5. Click the NAS Proxies tab. The page lists the NAS Proxies mapped to the NAS device.
  6. Click Add More Proxy
    The Add More Proxies window appears. The NAS Proxies tab on the window displays the list of proxies that you can map to the device. 

    AddMoreProxies.png
     
  7. Select the new NAS Proxy that you want to map to the NAS device and click Next.  
  8. Enter the NAS  device credentials on the NAS Credentials tab. Phoenix uses these credentials to access the NAS Share and perform backup and restore.
  9. Click Finish. The proxy gets mapped to the NAS device.
    You can also map this new proxy in the existing or new backup sets that you create under the NAS Share.  The proxy becomes available to the backup sets that you create for the shares configured on the device.

Configure backup set for NAS share

The configuration of a backup set comprises of :

  • Assigning storage where Phoenix backs up the NAS Share data.
  • Specifying the types of files and folders to back up
  • Assigning a backup policy
  • Assigning a NAS Proxy 

You can perform this procedure provided you have already added a NAS Share on the Phoenix Management Console.

To configure Backup Sets for NAS Share:

  1. Log on to Phoenix Management Console.
  2. Click the All Organizations list and select the organization with registered NAS devices.
  3. Click Protect > NAS
  4. Click the NAS device containing the NAS Share. The server page opens with Shares and NAS Proxies tabs. 
  5. Select the NAS Share for which you want to configure the backup sets.
  6. Click Create a Backup Set. The Add New Backup Set window is displayed.

    AddNewBackupSetWindow.png
     
  7. Enter details as described in the table below under Storage & Backup Content tab and then click Next.
    Field  Description
    Storage Select the Phoenix storage from the list which will store the data backed up from the NAS Share. Phoenix uses the same storage during restore.  After you configure a storage in a backup set, you cannot change it later.
    All folders Select to enable backup of all files and folders from the NAS Share, excluding those added to Exclude file types.

    Specific folders

     

    Select to enable backup of specific files and folders.

    Enter the relative paths of the folders that you want to backup and click Add. You can add multiple folder paths in this manner.

    Exclude file types

    Add files and folders that you want to exclude from the NAS Share backup.

    By default, Phoenix excludes video files, audio files, executables, and image files. It also excludes a specific set of subfolders from the backup by default. 

    To exclude more file types, type an extension preceded by an asterisk (*); for example, *.dotm and separate consecutive entries by using commas in the More file extensions to exclude text box. To exclude specific subfolders, enter the subfolder path or a wildcard exclusion in the Exclude subfolders text box and click Add

    The following wildcard support is available in the folder exclusion policy:

    • Wildcards without existing paths
      • Prefix (*abc): It excludes all the folders and files that end with “abc”.
      • Infix (*abc*): It excludes all the folders and files that contain the substring “abc”.
      • Postfix (abc*): It excludes all the folders and files that begin with “abc”.
    • Wildcards with existing paths
      • Prefix (Test/XYZ/*abc): The path must exist on the backup drive; otherwise, this wildcard exclusion is ignored. It excludes the folders and files that exist in the “Test/XYZ” folder and their names end with “abc”. This rule is applied only at given folder level.
      • Infix (Test/XYZ/*abc*): The path must exist on the backup drive; otherwise, this wildcard exclusion is ignored. It excludes the folders and files that exist in the “Test/XYZ” folder and their names contain “abc” as a substring. This rule is applied only at given folder level.
      • Postfix (Test/XYZ/abc*): The path must exist on the backup drive; otherwise, this wildcard exclusion is ignored. It excludes the folders and files that exist in the “Test/XYZ” folder and their names begin with “abc”.  This rule is applied only at given folder level.

     The file extension is considered as part of the filename.

    Include file types

    Add files and folders that you want to include in the NAS Share backup.

    By default, Phoenix includes Office files, PDF files, and HTML files in the backup.

    To include more file types, enter the file extensions separated by commas under More file extensions to include
  8. Assign an appropriate Backup policy from the list and click Next. The Backup Policy tab displays the details of the backup policy that you choose to assign to the backup set. 
    You can also use Create New Backup Policy to create and assign a new backup policy. For information on creating a backup policy, see Manage backup policies for NAS Shares
  9. Assign a NAS Proxy to handle the backup and restore from the NAS Share. 
    Phoenix displays the NAS Proxies based on the share type (SMB or NFS) you plan to back up. 
    The tab appears blank if you have not configured an appropriate NAS Proxy and mapped it to the NAS Share. 
  10. Click Finish.
    This competes adding and configuring a NAS Share on Phoenix Management Console. 

Configure Phoenix to backup and restore Oracle databases

Perform the following steps to backup Oracle databases:

  1. Deploy a Phoenix Backup Store
  2. Configure the Phoenix Backup Store

Deploy a Phoenix Backup Store

The following sections provide steps to deploy a Phoenix Backup Store:

Before you begin

Before you deploy the package and create the Phoenix Backup Store:

  • Ensure that the Ubuntu server or the virtual machine meets the hardware and software requirements specified in the system requirements article.
  • Ensure that the Phoenix Backup Store  uses Ubuntu 18.04. 
  • Set up the Phoenix Backup Store in your IT infrastructure so that the RMAN can access the mount on it and store the backups it creates.
  • Ensure that Internet access is enabled for the Phoenix Backup Store.
  • Read the quick steps article.

Download the Phoenix Backup Store package and generate activation token

The Phoenix Backup Store package is available on the Druva downloads page. In addition, you can download the package when you generate the activation token. If you want to:

  • Set up the Phoenix Backup Store on an Ubuntu server, download the Debian package 
  • Set up the Phoenix Backup Store as a virtual machine, download the Open Virtual Appliance (OVA) package

To generate the activation token: 

  1. Log in to the Phoenix Management Console.
  2. From the top menu, select the Organization where you want to configure the Phoenix Backup Store.
    The Organization page appears. 
  3. On the Organization page, click Protect > Oracle on the top menu bar. 
    The Oracle page appears. 
  4. On the Oracle page, click Register Phoenix Backup Store.
    The Register Phoenix Backup Store wizard appears.
  5. In the Install Package section of the wizard, use the Click here link to launch the downloads page and download the package. If you have already downloaded the package, click Next.
  6. In the Generate Activation Token section of the wizard, provide:
    Field Description
    Token Description A string that can help you identify the token.
    This token can activate <the number of> stores The number of Phoenix Backup Stores that can be activated using this token.
    The token expires in The number of days after which the token cannot be used for activating a Phoenix Backup Store.
    Click Next
  7. In the Store Activation section, Druva provides the activation token that you use to activate the Phoenix Backup Store. Copy the activation token, save it to a text file, and click Finish. You can also navigate to Manage > Tokens from the top menu bar to get the activation token again. 

After you generate an activation token:

Deploy the Debian package on an Ubuntu server and register the Phoenix Backup Store

The Debian package that you download is deployed on an Ubuntu server to create the Phoenix Backup Store. The mount created on the Phoenix Backup Store serves as the location to store Oracle RMAN backups. 

Prerequisite

Ensure that the package is accessible on the Ubuntu server.

Deploy the package
  1. Connect to the Ubuntu server using PuTTy or launch the terminal on the Ubuntu server. 
  2. Install the ZFS package on the Ubuntu server. The command to install the ZFS package is:
    sudo apt install zfsutils-linux=0.7.5-1*
    
  3. Install the NFS kernel package on the server. The command to install the NFS kernel package is:
    sudo apt install nfs-kernel-server=1:1.3.4-2.1*
  4.  On the terminal, run the dpkg command with the path to the Debian package to install it.
    sudo dpkg -i <path-to-the-Phoenix-Backup-Store-debian-package>
    For example:
    sudo dpkg -i /home/test-usr/Downloads/druva-phoenix-backupstore-4.7.6-110.amd64.deb

    Ensure that you provide the correct path to the location of the Debian package and its name.
    These steps install the ZFS package,  the NFS kernel, and the Druva binaries that Phoenix needs to create the Phoenix Backup Store. 

  5. [Optional] If the Ubuntu server on which you are deploying a the Phoenix Backup Store Debian package is a VMware virtual machine, perform the following steps to set disk.EnableUUID = True on the virtual machine:

    1. On the vSphere client that is connected to the vCenter/ESXi host, select the virtual machine that you are configuring as a Phoenix Backup Store and then turn it off.

    2. Select the virtual machine on the vSphere client, and then click Edit Settings

    3. In the Virtual Machine Properties dialog, select the Options tab.

    4. In the Options tab, select General under Advanced on the left pane.  

    5. On the right pane, click Configuration Parameters... in the Configuration Parameters section. The Configuration Parameters dialog appears.

    6. In the Configuration Parameters dialog that appears, update the value of the parameter with the name disk.EnableUUID to true and then click OK
      If disk.EnableUUID parameter is not listed under the Name column, click the Add Row button to add it and then set its value to true.

    7. Turn the virtual machine on.

  6. After the package is installed, perform the following steps to create a ZFS pool using the disks on the Ubuntu server:
    1. To get the disk IDs, run the following command on the command line terminal:
      ls -l /dev/disk/by-id/ 
      
      The output of the command looks like:
      drwxr-xr-x 2 root root 460 Jan  2 07:21 ./
      drwxr-xr-x 7 root root 140 Jan  2 07:21 ../
      lrwxrwxrwx 1 root root   9 Jan  2 07:17 ata-VMware_Virtual_SATA_CDRW_Drive_00000000000000000001 -> ../../sr0
      lrwxrwxrwx 1 root root   9 Jan  2 07:21 scsi-36000c291a9ac60a4f33cfce60c7b3860 -> ../../sdc
      lrwxrwxrwx 1 root root   9 Jan  2 07:21 scsi-36000c29484ebb93eaece5ac0dc845d08 -> ../../sdb
      lrwxrwxrwx 1 root root   9 Jan  2 07:17 scsi-36000c29b9dce7313dfdb13871518563a -> ../../sdd
      lrwxrwxrwx 1 root root   9 Jan  2 07:17 scsi-36000c29f3116f1d4f65e63c182d3ecf0 -> ../../sda
      lrwxrwxrwx 1 root root  10 Jan  2 07:17 scsi-36000c29f3116f1d4f65e63c182d3ecf0-part1 -> ../../sda1
      lrwxrwxrwx 1 root root  10 Jan  2 07:17 scsi-36000c29f3116f1d4f65e63c182d3ecf0-part2 -> ../../sda2
      lrwxrwxrwx 1 root root   9 Jan  2 07:21 wwn-0x6000c291a9ac60a4f33cfce60c7b3860 -> ../../sdc
      lrwxrwxrwx 1 root root   9 Jan  2 07:21 wwn-0x6000c29484ebb93eaece5ac0dc845d08 -> ../../sdb
      lrwxrwxrwx 1 root root   9 Jan  2 07:17 wwn-0x6000c29b9dce7313dfdb13871518563a -> ../../sdd
      lrwxrwxrwx 1 root root   9 Jan  2 07:17 wwn-0x6000c29f3116f1d4f65e63c182d3ecf0 -> ../../sda
      lrwxrwxrwx 1 root root  10 Jan  2 07:17 wwn-0x6000c29f3116f1d4f65e63c182d3ecf0-part1 -> ../../sda1
      lrwxrwxrwx 1 root root  10 Jan  2 07:17 wwn-0x6000c29f3116f1d4f65e63c182d3ecf0-part2 -> ../../sda2
      
    2. To create a ZFS pool, run the following command:
      ./zpool_config_no_raid.sh <disk-id-of-disk1> <disk-id-of-disk2> ... 
      
      For this example, the command to use the disks sdb and sdc is:
      ./zpool_config_no_raid.sh scsi-36000c29484ebb93eaece5ac0dc845d08 scsi-36000c291a9ac60a4f33cfce60c7b3860
      
    3. The above disk IDs are examples. Ensure that you provide the correct disk IDs when you create a ZFS pool.  To create a ZFS pool with RAIDZ configuration:

      • Use zpool_config_raidz1.sh in place of zpool_config_no_raid.sh

      • RAIDZ configuration requires at least three disks.

      • The scripts are stored under the /opt/Druva/Phoenix/PhoenixBackupStore/bin folder on the Phoenix Backup Store.

  7. Run the following command to restart the Phoenix Backup Store service:

    sudo service PhoenixBackupStore restart
  8.  After installing the package and configuring the ZFS pool, run the activation command with the token you generated above to activate the Phoenix Backup Store:

    PhoenixBackupStoreControl activate <govcloud> <activation_token>
    

    Example activation command for public cloud

    PhoenixBackupStoreControl activate ExampleToken1234
    

    Example activation command for Gov cloud

    PhoenixBackupStoreControl activate govcloud ExampleToken1234
    

    Ensure that you replace example values with real values. In the above syntax, replace ExampleToken1234 with the token that you generate. 

The Phoenix Backup Store is deployed and registered with Druva. 

For steps on how to deploy the Debian package on an EC2 instance, see Deploy the Debian package on an AWS EC2 instance with Ubuntu as its operating system.

Deploy the OVA package on a VMware setup and register the Phoenix Backup Store virtual machine

In addition to the Debian package, Druva provides an open virtual appliance (OVA) package that you can use to create a Phoenix Backup Store on a VMware setup. The OVA package that you download is deployed on a VMware setup to create the Phoenix Backup Store virtual machine. The mount created on the Phoenix Backup Store serves as the location to store Oracle RMAN backups. 

Before you begin

Ensure that the OVA package is downloaded.

Deploy the package

To deploy the Phoenix Backup Store OVA on a VMware setup, see Deploy an OVF or OVA template [External link to VMware documentation].

Note: When the vSphere client prompts you to review the deployment details in the fourth step of the deployment process, ensure that you click Next. The vSphere client shows this warning due to the advanced configuration options that Druva adds in the OVA package to ensure that the virtual disks get a static disk-ID which is required for creating a ZFS pool.
ova_deploy_warning1.png

The OVA package can be deployed for vCenter/ESXi version 6.0 or later. After you deploy the Phoenix Backup Store OVA, start the virtual machine and connect to the virtual machine using PuTTy or any other remote utility. To log in to the Phoenix Backup Store enter:

  • root as the username
  • PBS@123 as the password

After logging in, perform the following steps on the terminal:

  1. Create a ZFS pool using the virtual disks. The following procedure describes how to create a ZFS pool.
    1. To get the disk IDs, run the following command on the command line terminal:
      ls -l /dev/disk/by-id/ 
      
      The output of the command looks like:
      drwxr-xr-x 2 root root 460 Jan  2 07:21 ./
      drwxr-xr-x 7 root root 140 Jan  2 07:21 ../
      lrwxrwxrwx 1 root root   9 Jan  2 07:17 ata-VMware_Virtual_SATA_CDRW_Drive_00000000000000000001 -> ../../sr0
      lrwxrwxrwx 1 root root   9 Jan  2 07:21 scsi-36000c291a9ac60a4f33cfce60c7b3860 -> ../../sdc
      lrwxrwxrwx 1 root root   9 Jan  2 07:21 scsi-36000c29484ebb93eaece5ac0dc845d08 -> ../../sdb
      lrwxrwxrwx 1 root root   9 Jan  2 07:17 scsi-36000c29b9dce7313dfdb13871518563a -> ../../sdd
      lrwxrwxrwx 1 root root   9 Jan  2 07:17 scsi-36000c29f3116f1d4f65e63c182d3ecf0 -> ../../sda
      lrwxrwxrwx 1 root root  10 Jan  2 07:17 scsi-36000c29f3116f1d4f65e63c182d3ecf0-part1 -> ../../sda1
      lrwxrwxrwx 1 root root  10 Jan  2 07:17 scsi-36000c29f3116f1d4f65e63c182d3ecf0-part2 -> ../../sda2
      lrwxrwxrwx 1 root root   9 Jan  2 07:21 wwn-0x6000c291a9ac60a4f33cfce60c7b3860 -> ../../sdc
      lrwxrwxrwx 1 root root   9 Jan  2 07:21 wwn-0x6000c29484ebb93eaece5ac0dc845d08 -> ../../sdb
      lrwxrwxrwx 1 root root   9 Jan  2 07:17 wwn-0x6000c29b9dce7313dfdb13871518563a -> ../../sdd
      lrwxrwxrwx 1 root root   9 Jan  2 07:17 wwn-0x6000c29f3116f1d4f65e63c182d3ecf0 -> ../../sda
      lrwxrwxrwx 1 root root  10 Jan  2 07:17 wwn-0x6000c29f3116f1d4f65e63c182d3ecf0-part1 -> ../../sda1
      lrwxrwxrwx 1 root root  10 Jan  2 07:17 wwn-0x6000c29f3116f1d4f65e63c182d3ecf0-part2 -> ../../sda2
      
    2. To create a ZFS pool, run the following command:
      ./zpool_config_no_raid.sh <disk-id-of-disk1> <disk-id-of-disk2> ... 
      
      For this example, the command to use the disks sdb and sdc is:
      ./zpool_config_no_raid.sh scsi-36000c29484ebb93eaece5ac0dc845d08 scsi-36000c291a9ac60a4f33cfce60c7b3860
      
    3. The above disk IDs are examples. Ensure that you provide the correct disk IDs when you create a ZFS pool. The OVA that Druva provides comes with three disks. However, the first two disks with the storage capacity of 100 GB each are for backup and the third disk with the storage capacity of 200 GB is for restore. Ensure that you do not use the third disk with 200 GB storage capacity for creating the ZFS pool. 

    4. To create a ZFS pool with RAIDZ configuration:

      • Use zpool_config_raidz1.sh in place of zpool_config_no_raid.sh

      • RAIDZ configuration requires at-least three disks. Since the OVA ships with two disks for backup and one disk for restore, add a fourth virtual disk with the storage capacity of 100 GB and use the fourth disk along with the first and second disk. The Phoenix Backup Store uses the third disk with the storage capacity of 200 GB for restore. Ensure that you do not use the third disk with 200 GB storage capacity for creating the ZFS pool.

      • The scripts are stored under the /opt/Druva/Phoenix/PhoenixBackupStore/bin folder on the Phoenix Backup Store.

  2. Run the following command to restart the Phoenix Backup Store service. 
    sudo service PhoenixBackupStore restart 
  3. Run the activation command with the token you generated above to activate the Phoenix Backup Store:
    PhoenixBackupStoreControl activate <govcloud> <activation_token>
    

    Example activation command for Public cloud:

    PhoenixBackupStoreControl activate ExampleToken1234
    

    Example activation command for Gov cloud:

    PhoenixBackupStoreControl activate govcloud ExampleToken1234

    Ensure that you replace example values with real values. In the above syntax, replace ExampleToken1234 with the token that you generate. 

The Phoenix Backup Store is deployed and registered with Druva. 

Configure a Phoenix Backup Store

Phoenix Editions: File:/tick.png Business File:/cross.png Enterprise File:/tick.png Elite

After the Phoenix Backup Store is created, a mount must be created on the Phoenix Backup Store which serves as the location where Oracle Recovery Manager (RMAN) stores the database backups. Phoenix then creates a snapshot of the Oracle RMAN backup on the Phoenix Backup Store and uploads it to the Phoenix Cloud. 

The Phoenix Backup Store configuration includes the following steps:

  • Create a backup mount on the registered Phoenix Backup Store
  • Map the backup mount on the RMAN host
  • Let RMAN store backups on the mount

To backup databases:

Prerequisite

The Phoenix Backup Store is deployed and activated. For more information, see Deploy and register a Phoenix Backup Store.

Create a mount on the Phoenix Backup Store

To create a mount on the registered Phoenix Backup Store:

  1. Log in to the Phoenix Management Console.
  2. From the top menu, select the Organization where you want to configure the Phoenix Backup Store.
    The Organization page appears. 
  3. On the Organization page, click Protect > Oracle on the top-menu. 
    The Oracle page appears. 
  4. On the Oracle page, under the Phoenix Backup Stores tab, select a Phoenix Backup Store and then click Create Backup Mount.
    The Create Backup Mount wizard appears.
  5. In the Assign Administrative Group section of the wizard, select an existing administrative group or create a new one and click Next: Create Backup Mount. You see this section when you create a backup mount for the first time.
  6. In the Backup Mount Details tab of the wizard, provide:
    Field Description
    Backup Mount Name The backup mount name is the RMAN target location. The Backup Mount Name field identifies the Phoenix Backup Store mount where the Oracle RMAN backups are stored.  For example, testmount. Ensure that you enter alphanumeric characters only. 
    Storage The storage is the location on the Phoenix Cloud where the snapshot is stored after the Phoenix Backup Store uploads the snapshot to the Phoenix Cloud. 
    IP Whitelist The list of IP addresses of the Oracle RMAN hosts that can store Oracle RMAN backups on the mount.

    To allow multiple IP addresses, either use a comma or a wildcard. For example, if you enter 192.0.*.*, all the servers with the IP addresses starting 192.0.0.0 through 192.0.255.255 can access the mount. If you want to allow servers with specific IP addresses to access the mount, enter the IP addresses using a comma. For example, you want two servers with IP addresses 192.0.2.0 and 198.51.100.1 to access the mount. To allow access to the mount, enter 192.0.2.0, 198.51.100.1. 

    If no IP address is provided, any system can connect to the Phoenix Backup Store.
    Max Bandwidth Bandwidth available to the Phoenix Backup Store to upload the snapshots to the Phoenix Cloud. 
    After you provide all the details, click Next.
  7. In the Retention tab of the wizard, provide:

    Field  Description
    All Snapshots for <the number of> Days Phoenix retains all the snapshots that are created for the number of days specified in Daily snapshots.
    Weekly revisions for <the number of> Weeks Number of weekly snapshots that Phoenix should retain. Phoenix treats the latest snapshot in the week as the weekly snapshot.
    Monthly revisions for <the number of> Months Number of monthly snapshots that Phoenix should retain. Phoenix treats the latest snapshot in the month as the monthly snapshot.
    Yearly revisions for <the number of> Years Number of yearly snapshots that Phoenix should retain. Phoenix treats the latest snapshot in the year as the yearly snapshot.
    After you provide the retention settings, click Finish.

Phoenix creates a mount on the Phoenix Backup Store, and you can see it listed in the Backup Mounts tab of the Oracle page.

About the scripts on the Phoenix Backup Store

Druva provides scripts that are shipped with the Phoenix Backup Store. Use these scripts to configure the Phoenix Backup Store for backup and restore of Oracle databases. After you deploy the Phoenix Backup Store:

For Linux RMAN hosts:

  1. Log on to the Ubuntu server or the virtual machine that is set up as the Phoenix Backup Store.
  2. Transfer the following scripts from the Phoenix Backup Store to the server that hosts Oracle Recovery Manager (RMAN). The scripts are stored under the /opt/Druva/Phoenix/PhoenixBackupStore/bin folder on the Phoenix Backup Store.
    • phoenix_get_mount_details.sh:This script provides the details of the backup mount and the Phoenix Backup Store. Use this script to get the location of the backup mount so that you can map it to the RMAN host. 
    • oracle_rman_backup.sh:This script runs the RMAN commands that back up a database, create an Oracle RMAN backup and store it on the backup mount. You can modify this script to provide RMAN parameters that specify the type of backup and information related to backup like filesperset and channels for a backup. 

For Windows RMAN hosts, Druva provides a template batch file and an RMAN script to backup databases. The files are:

  • oracle_rman_backup.bat: This batch file runs the RMAN script that backs up a database. You can modify this script to provide RMAN parameters that specify the type of backup and information related to backup like filesperset and channels for a backup. 
  • rman_backup_windows.rman: This script runs the backup job on RMAN.

Note: The contents of the files for Windows RMAN hosts are available in this reference article. You can copy the contents of the files and create your own scripts to backup databases.

Backup Oracle databases using RMAN hosted on a Linux server

After you create a mount on the Phoenix Backup Store, you have to map it to the Linux server that hosts the RMAN. To map the mount to the RMAN host, you need the details of the backup mount which is a shared directory on the Phoenix Backup Store. Druva provides RMAN scripts that use the Phoenix Backup Store API to backup databases. For more information on how this script uses the Phoenix Backup Store API to backup and store Oracle RMAN backups on the backup mount, see Phoenix Backup Store API reference. To review the contents of the scripts, see Template shell scripts for Linux RMAN hosts.

In this example, the backup mount on the Phoenix Backup Store is mapped to the /local/testmount folder on the RMAN host. 

  1. After you transfer the scripts to the server that hosts the RMAN, run the phoenix_get_mount_details.sh script on the RMAN host with the IP address of the Phoenix Backup Store server and backup mount name as the parameters.

    Run the script as:

    ./phoenix_get_mount_details.sh <Phoenix-Backup-Store-ip-address> <backup-mount-name>
    For example:
    ./phoenix_get_mount_details.sh 192.0.2.1 testmount

    The output of the phoenix_get_mount_details.sh script is the path to the backup mount. You have to map the backup mount to the RMAN host so that when you run a backup job using the RMAN script, the RMAN can store the Oracle RMAN backup on the backup mount.

    Sample output of the RMAN script:

    Remote mountpath is 192.0.2.1:/Phoenix/testmount/oracle_data
    Mount options : retrans:5,timeo:1200, rw, user
    

    If you are using a Real Application Cluster (RAC) setup, the nfs mount should have NOAC option.

  2. Map the backup mount to the RMAN host after you generate its path. For example, if the RMAN host is  also Linux based,
    Run the following command for a standalone host: 
    sudo mount -t nfs <Phoenix-Backup-Store-IP-Address>:<path-to-backup-mount-on-Phoenix-Backup-Store> <path-to-local-folder-on-rman-host-for-mapping>

    For example:

    sudo mount -t nfs 192.0.2.1:/Phoenix/testmount/oracle_data /local/testmount

    Example command for a Real Application Cluster setup

    sudo mount -t -o noac,rw,user nfs 192.0.2.1:/Phoenix/testmount/oracle_data /local/testmount

    For more information on the mount command, see Ubuntu Manpage: mount [External link to Ubuntu Manpages].

  3. Add the folder as an entry to /etc/fstab to ensure that the backup mount stays mapped to the RMAN host if it is restarted.  For example:
    192.0.2.1:/Phoenix/testmount/oracle_data /local/testmount nfs rw,user,timeo=1200,noac
    • 192.0.2.1 is an example IP address of the Phoenix Backup Store.
    • /Phoenix/testmount/oracle_data is an example path to the backup mount on the Phoenix Backup Store.
    • /local/testmount is an example path to a folder on the RMAN host to which the backup mount is mapped. When RMAN writes data to this folder, data is actually written to the backup mount through NFS.
    • rw,user,timeo=1200,noac are applicable mount options. For more information, see Fstab [External link to Ubuntu documentation].
  4. Change the ownership of the mapped folder on the RMAN host. The ownership of the mount on the RMAN host should belong to the oracle/oinstall user.  Run the following command as the root user to change the ownership of the folder:
    sudo chown -R oracle:oinstall <path-to-local-folder-on-rman-host-to-which-backup-mount-is-mapped>

    For example:

    sudo chown -R oracle:oinstall /local/testmount

    or

    sudo chmod -R 777 /local/testmount
  5. After you map the backup mount to the RMAN host, you can backup Oracle databases. 

You can use the oracle_rman_backup.sh script on the RMAN host to run a backup job. The oracle_rman_backup.sh is a template script, and you can modify the script to change the  RMAN configuration parameters and to customize the data that you want to backup. Before you run the script, ensure that:

  • You have transferred the oracle_rman_backup.sh script to the RMAN host
  • You have the IP address of the Phoenix Backup Store that hosts the backup mount
  • You have the backup mount name

The run-time parameters of the oracle_rman_backup.sh script are: 

  • A folder path that will store the logs that the RMAN generates
  • IP address of the Phoenix Backup Store that hosts the backup mount
  • The name of the backup mount

To run the script:

  1. Open the terminal. 
  2. On the terminal, change directory to the folder in which the script is stored. 
  3. Run the script as the root user.
    ./oracle_rman_backup.sh <path-to-a-folder-on-rman-host-to-store-rman-logs> <ip-address-of-the-phoenix-backup-store> <name-of-the-backup-mount>
    For example:
    ./oracle_rman_backup.sh /home/test-usr/rman-log-directory 192.0.2.1 testmount

When the script is run, the RMAN creates an Oracle RMAN backup and stores it on the backup mount of the Phoenix Backup Store. All the logs of the Oracle RMAN backup job are stored in the folder you provide at the time of running the script. 

Backup Oracle databases using RMAN hosted on a Windows server

After you create a backup mount on the Phoenix Backup Store, you have to prepare the Windows server that hosts RMAN.  Druva provides RMAN script and a template batch file that use the Phoenix Backup Store API to backup databases. For more information on how this batch file uses the Phoenix Backup Store API to backup and store Oracle RMAN backups on the backup mount, see Phoenix Backup Store API reference. To review the contents of the scripts, see Template batch file and RMAN script for Windows RMAN hosts.  To prepare the Windows host for backup:

  1. On the Windows Server, install the Network File System [External link to Microsoft documentation]
  2. Enable Direct NFS Client for Oracle. The Direct NFS Client for Oracle optimizes the operations that RMAN performs to store backups on the Phoenix Backup Store mount. For more information, see Enabling Direct NFS Client [External link to Oracle documentation]
  3. Enable write permissions for the anonymous user on the Windows Server. With the write permissions, the anonymous user can write data on the backup mount of the Phoenix Backup Store.  To enable write permissions for the anonymous user:
    1. Run regedit to start the Registry Editor. 
    2. In the Registry Editor, navigate to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default folder in the left pane. 
    3. Create two DWORD 32-bit values in the folder. The two values create a user and group ID for the anonymous user that can write to the backup mount on the Phoenix Backup Store. To create the values:
      • In the right-pane, right-click and then select New > DWORD 32-bit value. Specify the name as AnonymousGID. Ensure that:
        • The value is either 0 or it matches the GID of the root user on the Phoenix Backup Store
        • Base is decimal
      • In the right-pane, right-click and then select New > DWORD 32-bit value again. Specify the name as AnonymousUID. Ensure that:
        • The value is either 0 or it matches the UID of the root user on the Phoenix Backup Store
        • Base is decimal
    4. Close the Registry Editor and restart the Windows Server. 
  4. Set up the curl utility on the Windows Server. For more information, see How do I set up and use cURL on Windows?

After the Windows Server is ready, you can use the oracle_rman_backup.bat and oracle_windows.rman scripts on the RMAN host to run a backup job. The oracle_rman_backup.bat is a template batch file, and you can modify it to change the  RMAN configuration parameters and to customize the data that you want to backup. Before you run the batch file, ensure that:

  • You have transferred the oracle_rman_backup.bat and oracle_windows.rman scripts to the Windows RMAN host
  • Installed the NFS Windows client through server roles
  • Direct NFS Client for Oracle is enabled
  • You have the IP address of the Phoenix Backup Store that hosts the backup mount
  • You have the backup mount name

The run-time parameters of the oracle_rman_backup.bat script are: 

  • A folder path that will store the logs that the RMAN generates
  • IP address of the Phoenix Backup Store that hosts the backup mount
  • The name of the backup mount

To run the batch file:

  1. Open the command prompt as admin on the Windows Server. 
  2. In the command prompt, change directory to the folder in which the batch file is stored. 
  3. Run the batch file. For example:
    oracle_rman_backup.bat C:\local\rman-logs-directory 192.0.2.1 testmount

The Phoenix Backup Store backs up the databases based on how you configure it. 

Related articles:

Configure CloudCache

This step is required only if you want to use CloudCache for your environment.

CloudCache temporarily stores backup data before it syncs the data with Phoenix Cloud. You need to install CloudCache on a Windows server in your own environment.

While adding a CloudCache server, Phoenix generates an activation token for it. Use this activation token when installing Phoenix CloudCache server and register the CloudCache server with Phoenix Cloud.

CloudCache_Activation_Token.PNG

The registered CloudCache server appears under the Unconfigured CloudCache tab of the Manage CloudCache page on Phoenix Management Console.

Configure your newly added CloudCache server to set up CloudCache server data volumes, set the schedule to sync CloudCache data to Phoenix Cloud, and do the bandwidth settings for uploading and downloading data.

Once you successfully configure the CloudCache server, you can map your servers to the CloudCache server by attaching the relevant backup set.

Related articles:

Configure disaster recovery plan for VMware

This step is required only if you want to use disaster recovery for your VMware setup.

Phoenix provides the disaster recovery as a service (DRaaS) feature for your VMware servers to extend the cloud-based data protection for enterprise infrastructure. Disaster recovery is based on the data that is already backed up. 

To manage the backed up virtual machines for disaster recovery, configure the DR plan. The DR plan is a set of rules for recovering your data in case of emergency or disaster.

A DR plan defines the following:

  • AWS account: The account in AWS that acts as a secondary site for Phoenix DRaaS. The account maintains the EBS snapshots for the virtual machines. At the time of disaster, you can launch EC2 instance from these EBS snapshots, in-turn spinning up to production in minutes.
  • AWS region: The storage region where you want to create EBS snapshots for the virtual machines. The region of the DR plan and region of the storage to which the virtual machine is backing the data to must be same.
  • Replication frequency: The frequency at which Phoenix updates the EBS snapshot. Based on the defined frequency, on each schedule, the existing DR copy, if present, is replaced with a DR copy based on the latest restore point available for the virtual machine.

Note: To configure the DR plan, you must need at least one registered Phoenix AWS proxy in the same region.

Deploying Phoenix DRaaS for VMware consists of the following tasks:

  1. Deploy Phoenix AWS proxy in the customer’s AWS account.
  2. Create a new DR plan.
    In a DR plan, you can define the replication attributes, such as the AWS account and region where you want to create DR copies for the virtual machines, schedules to update DR copy,  the virtual machines to failover, and so on. DR_create_new_plan1.PNG
  3. Attach a DR plan.
    To recover your virtual machines in the event of a disaster, you must add virtual machines to the DR plan. You can add virtual machines from multiple registered vCenters/ESXi hosts to the DR plan.
    Add_DR_Plan_Select_VMs.png

Related articles:

Monitor backup, restore, and disaster recovery activities

After configuring all your required Phoenix components you can monitor the progress of the backup and restore activities on the Jobs page.

Jobs_File.png

|View larger image|

You can access various reports to view the details of backup and restore activities. You can also download the report to your system or send the report through email in HTML or CSV format.

You can track the following reports and alerts:

  • Backup Activity
  • Restore Activity
  • Resource Status
  • Alerts History
  • Disaster Recovery Replication Activity
  • Storage Consumption by Backup Sets

Related articles:

Additional resources and help