Skip to main content
Druva Documentation

Understanding Phoenix workflows

These workflow diagrams explain the backup and restore processes for File servers, MS-SQL servers, NAS, and VMware infrastructure:

Data backup workflow

The following diagram illustrates how data flows within the Phoenix setup at the time of data backup. 

Step Description

Step 1

Phoenix agents installed on servers, back up server data according to the schedule defined in the backup policy. At the scheduled time, Phoenix Cloud initiates backups from servers on which Phoenix agents are installed.

Step 2

Phoenix agents attempt to communicate with Phoenix Cloud following a response-request messaging pattern over WAN.

Step 3

Phoenix Cloud validates agent communication requests. Upon successful validation, Phoenix Cloud assigns agent requests to storage.  

Step 4

Phoenix agents back up data to storage. 

Warm restore workflow 

A warm restore is a restore of data using snapshots that date back to 90 days in time (also referred to as warm snapshots). 

The following diagram illustrates how data flows within the Phoenix setup at the time of warm restore. 

Step Description

Step 1

Phoenix agents installed on servers send restore requests for data dating back to 90 days in time over WAN.

Step 2

Phoenix Cloud validates the requests and assigns them to storage. 

Step 3

Phoenix agents restore data from the storage that Phoenix Cloud assigned.  

File server backup workflow 

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

This article provides the workflow diagrams and the steps for data backup from the following operating systems:

Note:  If you restart or reboot your servers during backups, the backup operation is aborted. Phoenix agent starts a fresh backup following the backup schedule. Alternatively, you can start a manual backup at any time. 

File servers with Windows operating system

This topic explains how data flow during data backup from the File servers with Windows operating system.

file server backup on windows1.png

Backup workflow

Step Operation

Step 1

A backup request is initiated and forwarded to the Phoenix agent. 

Phoenix checks if Phoenix agent is running. 

  • If the agent is running, Phoenix performs the backup operation.
  • If the agent is not running, Phoenix performs the backup operation based on the type of backup job.
    • For a backup now job, Phoenix fails the backup request.
    • For a scheduled job, Phoenix waits until the expiry window of the backup request, else fails the backup request.

Step 2

Phoenix determines the type of backup.

If you or another administrator initiates the first backup, Phoenix performs a full backup. All subsequent backups triggered by administrators are incremental backups.

Step 3

 

Phoenix agent verifies that the VSS service is running. If the VSS service is not running, Phoenix agent starts the VSS service and instructs VSS to create a snapshot. 

Phoenix agent validates if snapshots are created successfully.

Step 4

Phoenix agent estimates the files and data to back up.

Step 5

 

  1. If snapshots are created successfully, Phoenix agent uses the VSS snapshots as the filesets for data backup to Phoenix Cloud.
  2. If the snapshots are not created successfully, Phoenix agent scans the live files and folders to create filesets for data backup to Phoenix Cloud.

Note: In case of VSS snapshots, Phoenix includes the locked files in the backup. However, in case of live folders and files scan, Phoenix considers locked files as missed files, and attempts to back up such files at the time of the next scheduled backup.

Step 6

After the backup completes, Phoenix agent deletes the created VSS snapshots.

File servers with Linux operating system

This topic explains how data flow during data backup from the File servers with Linux operating system.

file server backup on linux1.png

Backup workflow

Step Operation

Step 1

A backup request is initiated and forwarded to the Phoenix agent.

Phoenix checks if Phoenix agent is running. 

  • If the agent is running, Phoenix performs the backup operation.
  • If the agent is not running, Phoenix performs the backup operation based on the type of backup job.
    • For a backup now job, queues the backup request. The backup request is executed after Phoenix agent starts.
    • For a scheduled job, skips the backup request.

Step 2

Phoenix determines the type of backup.

If you or another administrator initiates the first backup, Phoenix performs a full backup. All subsequent backups triggered by administrators are incremental backups.

Step 3

Phoenix agent performs the full scanning of live files and folders on the File server.

Step 4

Phoenix agent estimates the files and data to back up. 

Step 5

Phoenix agent uses the scanned folders and files as the fileset for data transmission. 

Note: Phoenix considers locked files as missed files, and attempts to back up such files at the time of the next scheduled backup. 

File server restore workflow

Restore workflow on the same File server

Restore workflow on a new File server 

Steps to restore File server 

Step Operation

Step 1

You or another administrator initiates a restore operation.

You can restore the data at the original location or an alternate location. The alternate location can be the same server and different path or different server and different path.

You can select the destination server where restore can happen for the selected File server restore point. For example, Windows server for Windows restore and Linux server for Linux restore.

Step 2

Phoenix checks if Phoenix agent is running. 

  • If the agent is running, Phoenix performs the restore operation.
  • If the agent is not running, Phoenix queues the restore request and performs the restore operation after Phoenix agent starts.

Step 3

Phoenix validates the restore destination. 

Step 4

Phoenix checks the free space available at the restore destination.

Step 5

Phoenix identifies the file sets for restore.

Step 6

Phoenix starts the restore operation and sequentially downloads the filesets to the restore destination.

 Note: For more information about restoring File servers, see Restore a File server to the same serverRestore the File server to a different server.

NAS Share backup workflow

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

This article provides the workflow diagrams and steps for data backup of NAS shares on Windows and Linux. 

Backup workflow

The following workflow illustrates the data flow during backup of NAS shares on Windows or Linux: 

NASBackupWorkflow.png

 

The following table summarizes the workflow steps. 

Step Operation

Step 1

 A backup request is initiated and forwarded to the NAS proxy. 

Step 2

 

Phoenix checks if the NAS proxy is running. 

  • If the proxy is running, Phoenix performs the backup.
  • If the proxy is down, Phoenix performs the backup based on the type of backup job, as specified below.
    • For a backup now job, Phoenix queues the backup request. Phoenix completes the request after the NAS proxy starts.
    • For a scheduled job, Phoenix skips the backup request.

Step 3

 

Phoenix determines the type of backup.

If it is the first backup from any source, Phoenix performs a full backup. The subsequent backups are incremental backups.

Step 4

Phoenix agent performs a full scan of the files and folders on the NAS share.

Step 5

NAS proxy sends the scanned files and folders for backup to Phoenix Cloud.

Note: If Phoenix is unable to back up  locked files at the first attempt, it checks if the files are unlocked at the end of the backup. If the files are unlocked, they are backed up in the same backup cycle.  Locked files are not backed up.
Step 6 Phoenix Cloud applies deduplication and saves incremental data in snapshots.

 

NAS Share restore workflow

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

Workflow to restore on the source NAS share 

RestoreToSameLocation.png

Workflow to restore on a different NAS share 

RestoreToAlternateLocation.png

Steps to restore a NAS device

Step Operation

Step 1

You initiate a restore operation.

You can select the destination share for the restore of the selected NAS restore point. For example, SMB share for a Windows restore and NFS share for a Linux restore.

Step 2

Phoenix checks if the NAS proxy is running. 

  • If the proxy is running, Phoenix performs the restore operation.
  • If the proxy is not running, Phoenix queues the restore request and performs the restore operation after the NAS proxy starts.

Step 3

Phoenix checks whether the share type of the restore destination is same as the sources and validates the restore request.

Step 4

Phoenix identifies the snapshots to restore.

Step 5

Phoenix starts the restore operation and sequentially downloads the snapshots to the restore destination.

 Note: For more information about restoring a NAS share, see Restore a NAS share.

What you must know about NAS share restore 

This section highlights the important considerations of the NAS share restore:

  • Hot snapshots reside on the Phoenix CloudCache for the period specified in the CloudCache configuration. See Configure Phoenix CloudCacheCloudCache for information on the configuration.
  • If you are a group administrator, you can restore data only to the NAS share that belongs to the administrative group that you manage. Cloud administrators and data protection officers can restore data to shares across all administrative groups.
  • You can restore data only to a share that has the same operating system as the source share. 
  • In the event of a network connection failure during restore, the NAS proxy attempts to connect to the Phoenix Cloud. After the network connection is restored, the NAS proxy restarts the restore from the state where it was interrupted. 
  • If you restart or reboot the NAS device during a restore, the restore operation is aborted. 
  • If you choose to restore data to the same location, the existing data at that location is overwritten unless a different restore setting is configured.
  • The time zone for the snapshot timestamp and the file/ folder timestamp may differ if the NAS proxy and NAS shares are in different time zones.
  • Long file and folder names are now visible in the Restore Data page. The Date Modified and Size information is visible on the next line.
  • Restores are not supported to mapped drives.
  • For SMB shares:
    • The following file attributes are supported:
      • Not content-indexed
      • Read-only
    • All the Access Control Lists (ACLs) are restored.
  • For NFS shares,
    • File permissions for file owners, groups, and users are restored.
    • File attributes are not supported.
    • ACL permissions are not supported.
    • The following special permissions for files and folders are not supported:
      • Setgid
      • Sticky bit
      • Setuid
  • Backup and restore can run simultaneously on the same agent.
  • The backup request triggered while a restore is in progress will be queued.
  • Full scan restore will be marked with an  icon.

MS-SQL Server backup workflow

Full backups

Phoenix performs an ever incremental backup of the databases of your MS-SQL servers. As mentioned in the prerequisites, backup and restore operations depend on VSS and SQL writer services. When a full backup is triggered based on the backup policy, Phoenix agent communicates with the SQL writer service using the VSS framework. The Phoenix agent executes a full scan of all the databases included in the backup. If your databases are getting backed up for the first time, the databases are backed up entirely. If your databases are not getting backed up for the first time, a full scan of the databases is executed but only the updates to your databases are backed up after deduplication is applied. When the backup job is successful, Phoenix creates a snapshot (Restore Point) in your storage.

Understanding snapshots created using full backup

When you specify the number of days to keep all snapshots in the daily retention period, all the snapshots created within that period are retained.

For example, in your retention period, you specify keep all snapshots for 10 days. In your backup policy, the full backup is scheduled to run on Wednesday, 12:00:00 PM PST for every week.

Between February 1, 2017, and February 28, 2017, Wednesday falls on 1st, 8th, 15th, and 22nd. The full backup is triggered on February  1, 2017, and a snapshot is created at 4:00:00 PM when the job is successful.

On February 8, 2017, another full snapshot is created at 3:00:00 PM. Since all snapshots are retained for 10 days, before February 11, 2017, 11:59:59 PM, the full snapshots created on February 1, 2017, and February 8, 2017, are retained. After February 11, 2017, 11:59:59 PM, the February 1, 2017 snapshot is retained based on your weekly, monthly, and yearly retention periods.

Workflow

The full backup contains the following steps:

  1. Phoenix checks if the agent is running. If the agent is not running, Phoenix queues the backup request. The request is executed after Phoenix agent is up and running.
  2. Before the backup operation starts, agent checks if VSS Service and SQL Writer service are running or not. If the services are not running, then the agent attempts to boot these processes automatically.
  3. During the estimate phase, the agent fetches the database information from MS-SQL server using the Volume Shadow Copy API.
  4. The agent then determines the distinct filesets, which should be backed up. VSS then provides a snapshot.
  5. If you are backing up your databases for the first time, entire snapshot is backed up. If you are not backing up your databases for the first time, updated data, in terms of filesets, is copied from the snapshot and uploaded to the server. The backup is marked as successful after data is successfully uploaded to the server.

Additional information

  • The VSS snapshot is transient and is deleted automatically by the operating system. If the hard drive is not accessible, the VSS and MS-SQL server may take some time to recognize and update their internal file information.
  • Backup may fail if it is triggered during this time interval while database files are moved to the partition containing deleted files.
  • Backup jobs can be completed successfully after VSS and MS-SQL server update internal file information. But if some database files are moved to the deleted files partition and some other files are still available on the logical partition, the backup always fails. As a workaround, you have to clean this database manually.
  • The system database tempdb is never backed up.
  • During backup, database entities get backed-up in following order:
    • Database files: MDF, LDF and NDF files
    • Agent-specific metadata (json data)
    • VSS backup document (XML data)
    • SQL Writer metadata document (XML data)
    • Sentinel (json data)
  • On your server, if
    • DB1 has files at C:\Data
    • DB2 has files at C:\Data
    • DB3 has files at C:\Program Files\Data

The agent identifies C:\Data and C:\Program Files\Data as two filesets, and are uploaded sequentially. However, the files within a fileset are uploaded in parallel.

Differential backups

MS-SQL servers provide the differential backup functionality. When a differential backup is triggered, the agent requests information about databases that are updated. Phoenix backs up the differential data and creates a snapshot in your storage. A differential backup can be triggered if a snapshot from a full backup exists. If a snapshot from a full backup does not exist, a differential backup is automatically converted into a full backup job. For more information, see Scenarios when the SQL differential backups get converted to full backups.

Note: When you click Backup Now, differential backup is triggered. However, if your server is getting backed up for the first time, Full Backup is triggered. A manual backup is not restricted by bandwidth you specify, it uses maximum bandwidth available.

Restoring from a snapshot created using a differential backup

If you are restoring your database on February  13, 2017, at 11:00:00 AM,

  • The snapshots after differential backups on February 1, 2017, and February 2, 2017, are purged.
  • In the warm snapshots, you can see snapshots after differential backups created starting February 3, 2017, through February 12, 2017.
  • You can see snapshots created after full backup on February 1, 2017, and February  8, 2017.

Since all the snapshots above fall under warm snapshots, you can select any snapshot as a restore point, and use it to restore your database. However, when you select a snapshot created after a differential backup, Phoenix uses a full backup snapshot created right before it. Typically, full backup snapshot created on February 1, 2017, is purged based on 10 day retention period. But when you select a differential snapshot created before February 8, 2017, for restore, Phoenix requires the full backup snapshot created on February 1, 2017. Since there are differential backup snapshots that are retained and are tied to the February 1, 2017, snapshot, the February 1, 2017 snapshot is retained.

Workflow

A differential backup contains the following steps:

  1. Phoenix checks if the agent is running. If the agent is not running, Phoenix queues the backup request. The request is executed after Phoenix agent is up and running.
  2. Before the backup operation starts, agent checks if VSS Service and SQL Writer service are running or not. If the services are not running, then the agent attempts to boot these processes automatically.
  3. During the estimation phase, the agent fetches the database information from SQL Server using the Volume Shadow Copy API.
  4. For differential backup, SQL server provides updates to databases since the last backup. Phoenix uploads these changes to the server.  Backup is marked successful when the files are successfully uploaded to the server.

Scenarios where Phoenix converts SQL differential backups to full

Phoenix converts differential backups to full backups, if: 

  • A differential backup of a database for which a full backup is not complete is attempted. 
  • A new database file is added to or deleted from a database since the last backup.
  • A database file is renamed or moved since the last backup.
  • A database was renamed.
  • Inconsistencies between the uploaded database files and its metadata are detected. 
  • The master database was included in the last full backup, and the path or name of the master database files changed since the last full backup.
  • Phoenix cannot obtain details about data change from the Volume Shadow Copy Service.
  • A full backup fails, then the next differential backup will be converted to a full backup.
  • If a full backup is executed by Phoenix MS-SQL agent and the second full backup is been executed by a third-party backup tool or MS SQL server. Then Phoenix agent can convert next differential backup to full backup. 
  • If a database is encountered as shrunk since last full/differential backup, Phoenix converts the subsequent differential backups to full backups. 
  • Phoenix cannot take a differential backup on a secondary node of an availability group. In such a case, Phoenix runs a full backup. 
  • If a database is moved, deleted, or added to a backup set, Phoenix converts the next differential backup for all the affected backup sets to full. 

Transaction log backups

Transaction log in MS-SQL servers records all the updates to the servers. Phoenix frequently backs up the transaction log based on the intervals you provide in the backup policy, and are triggered after a full or differential backup is complete. When Phoenix backs up transaction logs, transaction logs are truncated on the MS-SQL server. If a full backup is not complete for a server even once, the transaction log backups are not triggered. Transaction logs provide a tighter restore point objective and are dependent on snapshots created using the full or differential backup. Log backups are not applicable for databases in simple recovery mode. 

Understanding log backup schedules

Backed up transaction logs are retained based on daily retention period. Weekly, monthly, and yearly retention policies are not applicable for log backups.

For example, you specify an interval 30 minutes for log backups. In the example above, the full backup is triggered on February 1, 2017 at 12:00:00 PM, and completes on February 1, 2017 4:00:00 PM. At 4:30 PM, a log backup is triggered. Subsequently, the transaction log is backed up every 30 minutes until 9:00:00 PM when differential backup kicks in.

Restoring from a transaction log

When you restore your database using a transaction log, you can:

  • Choose a point-in-time when a transaction occurred
  • Choose a marked transaction in the transaction log and restore your database to that point.
  • Choose a point-in-time when a transaction occurred and leave the database in standby mode

When you choose a point-in-time or a marked transaction, Phoenix restores your database using a snapshot. After restoring your database using a snapshot, it applies transaction logs to your database up to the selected transaction. This lets you restore your database to a time between two snapshots, allowing a tighter restore point objective.

Workflow 

The following flowchart depicts the transaction log workflow:

new_log_backup_workflow.png

Limitations on transaction mark backup and restore for AG backup sets

Phoenix does not back up transaction marks if the log backups are taken from any secondary nodes. 

MS­-SQL server does not replicate transaction marks related to the transaction logs on the secondary nodes for databases in availability group (AG). If you try to restore a transaction mark for an AG backup set from Phoenix, you might or might not see transaction marks that were created on the MS-SQL server depending on whether the log backup happened from the primary or secondary node. 

MS-SQL Server restore workflow

Database snapshot restore workflow

The following steps describe the restore job when you trigger a snapshot restore of your databases of the instances or AG.

Step Operation

1

You or another administrator initiates a restore. 

2

Phoenix checks if the Phoenix agent is running. 

  • If the agent is running, Phoenix executes the restore operation.
  • If the agent is not running, Phoenix queues the restore request. The request is executed after the Phoenix agent on the MS-SQL server starts running.
3 Phoenix validates the restore destination (original instance or another MS-SQL server). 

4

Phoenix validates if the restore destination is not a drive. For example, a restore to D:\ fails. 

Note: Set a restore location to a subfolder, and not the drive, for example, D:\ThisFolder.  

5 Phoenix validates if the instance to which restore is initiated is available. 
6 Phoenix validates if the databases for restore are available. 
7 Phoenix checks the free space available at the restore destination. 

8

Phoenix starts the restore operation by identifying filesets for restore. Phoenix sequentially downloads filesets to the restore destination. Within a fileset (which might contain data belonging to more than one database), Phoenix performs a simultaneous download of files belonging to different databases. After the download of a fileset completes, Phoenix downloads the next fileset (which might also contain data belonging to one or more databases) to the restore destination.

9

Phoenix uses the following syntax for the restore: <destination path>\<snapshot>\<Request ID>\<Fileset>\<Actual file>. The <Request ID> folder uniquely identifies each restore request.

10

Additionally, Phoenix also creates the database_files.txt file at D:\restore\<snapshot>\<Request ID>. This file contains details of how the database files are mapped to the database, and how the database is mapped to its instance in a Unicode format. 

11

At the location that you specified, Phoenix restores the databases as rst_<Database Name>. However, if Phoenix finds that rst_<Database Name> is already present at the location, it appends an incremental counter to the database name. For example, at the time of restoring database DB, if Phoenix finds rst_DB from a previous restore operation, the database DB is restored as rst_DB_1. The counter increments by 1 for every occurrence of an existing restore dataset.
12 In case of restore to AG, Phoenix repeats Step 9 on all the secondary nodes of the AG. Phoenix backs up the database to the shared network location provided by you and the restored database is replicated on all the primary and secondary nodes of the AG. 

13

After the restore completes,

  1. If "Recovery mode" is selected, the database becomes active for the instance that you specified. 
  2. If "No recovery mode" is selected, the database appears as "Restoring" for the instance that you specified.
  3. If "Standby mode to allow restore of additional transaction logs" is selected, the database appears as Standby/ Read-Only for the instance that you specified. 
  4. If "Restore to Availability Group" is selected, the database appears as synchronized on all the nodes of the AG.

Point-in-time restore workflow

The following table depicts the point-in-time restore workflow using transaction logs:

Step Operation

1

You initiate a point-in-time restore.

2

 

Phoenix checks if the Phoenix agent is running. 

  • If the Phoenix agent is running, Phoenix runs the restore job.
  • If the Phoenix agent is not running, Phoenix queues the restore job. The restore job is completed after the Phoenix agent starts running. 

3

Phoenix validates the restore destination (Original, alternate, or availability group) and the location on the restore destination.

Note: Ensure that the location is not a drive. For example, C:\.  To restore a database, restore the database files to a sub-folder. For example, C:\DBFiles.

4 Phoenix validates if the SQL Server instance is available for restore. If the restore job replaces the original database, Phoenix also checks if the database is available for restore. 
6 Phoenix checks the free space available for restore and starts the restore job by identifying filesets for restore. Phoenix sequentially downloads filesets to the restore destination. Within a fileset (which might contain data belonging to more than one database), Phoenix simultaneously downloads files that belong to different databases. After the download of a fileset completes, Phoenix downloads the next fileset (which might also contain data that belongs to one or more databases) to the restore destination.
7 Phoenix uses the following syntax for the restore: <destination path>\<snapshot>\<Request ID>\<Fileset>\<Actual file>. The <Request ID> folder uniquely identifies each restore job.

8

The Phoenix agent picks up the transaction logs from the restore location, and:

  • Picks the user-specified date and time (or the selected marked transaction)
  • Checks which mode is enabled for restore:
    • If Recovery mode is enabled, Phoenix restores the database and leaves the database in the operational state (you cannot add more backup sets to it).
    • If No recovery mode is enabled, Phoenix restores the database and leaves the database in a pending state that cannot be accessed. 
    • If Standby mode is enabled, it identifies the transaction closest to the date and time specified. Phoenix restores the database changes up to the identified transaction using the transaction log. In addition, it downloads the log files containing the transactions after the point-in-time restore. 

If the original database is getting replaced, the Phoenix agent terminates all connections to the database and then restores it using the downloaded transaction logs. 

9 If the database is restored to an availability group, the Phoenix agent either restores the database to the specified shared network location and syncs the database to all the secondary nodes or uses the automatic seeding if available. 

After the restore completes: 

  • If Recovery mode is selected, the database appears as active for the instance that you specified. 
  • If No recovery mode is selected, the database appears as Restoring for the instance that you specified.
  • If Standby mode to allow restore of additional transaction logs is selected, the database appears as Standby/Read-Only for the instance that you specified. 
  • If Restore to Availability Group is selected, the database appears as synchronized on all the nodes of the AG.

Oracle database backup workflow

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

The Phoenix backup workflow for Oracle is described below:

WelcomeOracleGraphics2x.png

Step Description
Step 1 An Oracle Database Administrator triggers the RMAN script with the name of the mount on the Phoenix Backup Store. The RMAN creates an Oracle RMAN backup and stores it on the mount. 

The Phoenix Backup Store creates a snapshot of the Oracle RMAN backup stored on the mount. 
Step 2 The Phoenix Backup Store creates a ZFS snapshot of the Oracle RMAN backup and applies a timestamp to the snapshot. 

The timestamp corresponds to the PUT request made to the Phoenix Backup Store after RMAN completes writing the Oracle RMAN backup to the backup mount. For more information, see Phoenix Backup Store API reference.
Step 3 Phoenix Backup Store uploads the snapshot to the Phoenix Cloud. This snapshot serves as a restore point.
After the snapshot is uploaded to the cloud, it is deleted from the Phoenix Backup Store.

Every time the Database Administrator runs the RMAN script, the RMAN creates an Oracle RMAN backup on the mount. The Phoenix Backup Store creates a new snapshot of every new Oracle RMAN backup that RMAN creates and stores on the mount and uploads the snapshot to the cloud creating a new restore point. 

RMAN can store backup data until sufficient storage is available on the Phoenix Backup Store.  If sufficient storage is not available, RMAN cannot store backups and the backup jobs fail. Ensure that you periodically remove Oracle RMAN backups from the the Phoenix Backup Store or increase storage capacity on it. 

Oracle database restore workflow

Oracle_workflow_restore_1.png

Step Operations

Step 1

Phoenix administrator selects a snapshot and initiates a restore.

Step 2

Phoenix administrator can restore a snapshot to the original Phoenix Backup Store or an alternate Phoenix Backup Store. 

Step 3

The snapshot is unpacked and downloaded as an Oracle RMAN backup to a location on the Phoenix Backup Store. The Oracle RMAN backup download location on the Phoenix Backup Store is /mnt/restores/<backupmount_name>/<restore_job_id>/data where:

  • The mount-name is the name of the mount you selected to restore.
  • Job id is the ID of the restore job. You can get the job ID from the jobs page. 

Step 4

The snapshot location is mapped to the RMAN host so that RMAN can use data stored on it to restore databases to the Oracle instance. 

Step 5

The Database Administrator restores the Oracle RMAN backup to the Oracle instance.  

VMware virtual machine backup workflow 

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

Phoenix performs backup on virtual machines based on the schedule defined in the backup policy, that virtual machine is a part of or an on-demand backup triggered from Phoenix Management Console. This involves the interaction of Phoenix components and VMware components.

The following diagram depicts the data flow at the time of backing up virtual machines.

|View larger image|

Virtual machine backup workflow

Step Operation

Step 1

Virtual machine backup request is initiated based on,

  • Schedule defined in the backup policy.
  • Manual backup

Phoenix forwards the backup request to the backup proxy pool.

  • Based on the load balancing algorithm, Phoenix automatically identifies the backup proxy that will run the backup request.
  • If the identified backup proxy is busy, the backup request is queued and initiated when the backup proxy becomes free.

Step 2

  • In an environment where virtual machines are deployed on ESXi hosts managed by vCenter server, backup proxy contacts vCenter Server to locate the virtual machine and obtains its configuration.
  • In an environment where virtual machines are deployed on standalone ESXi hosts, backup proxy contacts ESXi host to obtain the virtual machine configuration.

Step 3

The backup proxy queries the ESXi hypervisor or the vCenter server to create VM snapshots that contain VMDK files and the VMX files of the virtual machines.  Ensure that enough storage is available on the local datastore for the VM snapshot.

The backup proxy uses CBT and Tools Quiescing to create a virtual machine snapshot. For the first automatic backup, the backup proxy creates a snapshot of a full backup. For all subsequent backups, the backup proxy creates snapshots of the incremental backups. 

Step 4

Backup proxy establishes a VDDK connection to the VM snapshot using a transport mode to read the VM data. 

Reading encrypted VMDK through the NBD mode is not supported. The backup proxy can read encrypted VMDK disks either using NBDSSL or HotAdd. Here are the supported transport modes:

Backup proxy Virtual Machine Transport mode
Encrypted Encrypted HotAdd
Unencrypted Encrypted NBD-SSL
Encrypted Unencrypted HotAdd

Step 5

Backup proxy starts reading the virtual machine snapshot. 

Note: The backup proxy reads the VM snapshot on the local datastore.

Step 6

The backup proxy reads the virtual machine snapshot and prepares to send the backup data to Phoenix CloudCache (if configured) or Phoenix Cloud.

Step 7

Backup proxy transfers the backup data in a continuous stream to the Phoenix Cloud. Before transferring the data to the Phoenix Cloud, the backup proxy performs the de-duplication.

After the transfer completes, the backup proxy deletes the snapshot stored on the local datastore. 

VMWare virtual machine restore workflow

 

 

Step Operations

Step 1

Phoenix administrator initiates virtual machine restore. Phoenix forwards the restore request to the backup proxy pool.

  • Based on the load balancing algorithm, Phoenix automatically identifies the backup proxy that will fulfill the restore request.
  • If the identified backup proxy is busy, the restore request is queued and initiated when the backup proxy becomes free.

Step 2

Phoenix performs a check to ensure that the restore location is not a Network-attached Storage (NAS).

  • In an environment where virtual machines are deployed on ESXi hosts managed by vCenter Server, backup proxy contacts vCenter server to locate the virtual machine.
  • In an environment where virtual machines are deployed on standalone ESXi hosts, backup proxy contacts ESXi host and locate the virtual machine.

Step 3

VDDK connection is established with the virtual machine with SSL transport mode.

Step 4

Backup proxy checks if it is a full virtual machine restore or a VMDK file restore. Backup proxy contacts the virtual machine and establishes a write connection to restore virtual machine data.

  • For a full virtual machine restore:
    • Phoenix deletes the virtual disks (VMDKs) of the existing virtual machine
    • Phoenix creates a new virtual machine with an identical configuration (that is, the configuration of the virtual machine at the time of backup)

      Note: If new virtual disks (VMDKs) are present during the current restore operation but were not present during the backup operation, Phoenix detaches these virtual disks (VMDKs). 

    • Phoenix restores the virtual disks (VMDKs) of the virtual machine
    • Phoenix does not change the name or any other configuration of the virtual machine
  • For a disk restore, Phoenix creates a new virtual machine with minimum configuration (100 MB RAM, 1 CPU, 1 video card, and the disk to be restored) at the location specified, with the following syntax: 
    <Name of the original virtual machine>_<counter>.
Note: For disk restore, create a minimum configuration virtual machine because VMware does not allow to create a disk without creating the virtual machine.

Step 5

Backup proxy obtains the virtual machine data from Phoenix Cloud.

Step 6

Restore operations starts.

Phoenix checks if the restore completes successfully. 

  • If the restore completes successfully, a new virtual machine is available.
  • If the restore fails, Phoenix deletes the newly-created virtual machine.

Hyper-V virtual machine backup workflow

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

Phoenix backs up virtual machines based on the schedule defined in the backup policy, or if a backup is triggered from Phoenix Management Console. The backup workflow is explained below:

hyperV_backup_workflow-4.png

Virtual machine backup workflow

Step Operation

Step 1

Virtual machine backup request is initiated based on:

  • Schedule defined in the backup policy.
  • On-demand backup

Phoenix forwards the backup request to the agent.

Step 2

Phoenix agent verifies that the VSS service is running. The Phoenix agent requests the VSS service to create a snapshot. If the VSS service is not running, Phoenix agent starts the VSS service and instructs VSS to create a snapshot.

Druva recommends that you enable Backup (volume snapshot) under Hyper-V Integration Services. If the Backup (Volume snapshot) is enabled, the VSS service can create a snapshot without interrupting services on the virtual machine.

Phoenix agent validates if snapshots are created successfully and initiates the backup job.
For  Windows Server 2008 and Windows Server 2008 R2 host:

  • If Phoenix is backing up virtual machines that are stored on a clustered shared volume, then Phoenix can backup only one virtual machine at a time. 
  • A hardware VSS provider is required if  you want Phoenix to create snapshots for multiple virtual machines simultaneously on a single host and run parallel backup jobs. For information on how to configure Phoenix so that it can use third party VSS providers, see How do I configure Phoenix to use third party VSS providers?.
Note: Integration Services are available for virtual machines with Windows guest OS. However, Microsoft provides Integration Services for certain Linux distributions also. For more information, see: If integration services are not available for a virtual machine, Phoenix cannot take a snapshot and backup fails.

On Windows Server 2016 or later, the Phoenix agent can back up virtual machines using the Resilient Change Tracking (RCT) feature if:

  • The Phoenix agent installed on the host is 4.7.5 or later, and
  • Virtual machine configuration version is 6.2 or later. If the virtual machine is hosted on a Hyper-V cluster, then the virtual machine cluster functional level must be level 9 or higher. 

The Phoenix agent can back up virtual machines using RCT on a Hyper-V host that meets the criteria above and:

  • Efficiently keep a track of what has changed on a virtual machine between backup jobs
  • Incremental backups will be faster

Note: The Phoenix agent can take virtual machine snapshots using the RCT feature if it is backing up virtual machines for the first time from a host that meets the criteria. The Phoenix agent continues to use VSS if snapshots of the virtual machines from a host exist that were created using VSS. However, if:

  • VSS snapshots exist from a host that meets the criteria above, and
  • You want subsequent backup jobs to use the RCT feature   

Upgrade the Phoenix agent on the host and change backup method to RCT.  

Step 3

Phoenix determines the type of backup. 

  • If this is the first automatic backup, Phoenix performs a full backup. 
  • For all subsequent backups, Phoenix performs an incremental backup. 

 

Step 4

Agent estimates the data for backup

Step 5

Agent backs up the data based on the VSS provided snapshot

Next steps

If you want to configure Phoenix for backup and restore, see:

To learn more, see:

Hyper-V virtual machine restore workflow

hyperV_restore_workflow-2.png

Step Operations

Step 1

Phoenix administrator initiates virtual machine restore. Phoenix forwards the restore request to the Hyper-V server agent.

You can restore your virtual machine to the original location or an alternate location. Ensure that the Phoenix agent is activated and the destination Hyper-V server is registered with Phoenix as a host. 

Step 2

Phoenix checks if the Phoenix agent is running. If the agent is running, Phoenix restores the virtual machine. If the agent is not running, the restore job is queued until the agent is ready for backup and restore. 

Step 3

Phoenix agent checks if the destination Hyper-V server has sufficient storage to restore the virtual machine.

Step 4

Phoenix agent checks if it is a full virtual machine restore or a virtual disk restore. Agent contacts the server and establishes a write connection to restore virtual machine data.

  • For a full virtual machine restore, Phoenix creates a new virtual machine with an identical configuration (that is, the configuration of the virtual machine at the time of backup) at the similar location, with the following syntax: 
    For original location restore: <Name of the original virtual machine>_<counter>
    For alternate restore <user provided virtual machine name>_<counter>
  • For a disk restore, Phoenix restores the disk on the location you select. 

Step 5

Phoenix Cloud sends the snapshot to the Hyper-V server agent.

Step 6

Restore operations start.

Phoenix checks if the restore completes successfully. 

  • If the restore completes successfully, a new virtual machine is available.
  • If the restore fails, Phoenix deletes the newly-created virtual machine.

Phoenix disaster recovery workflow 

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

Disaster recovery stages

The following table lists the different stages of the disaster recovery process.

For definitions of different terms and concepts used in DRaaS see, Disaster recovery concepts

Stage Description
Restore

With Phoenix DRaaS, the Phoenix AWS proxy:

  • Reads the virtual machine backup data from the Phoenix Cloud
  • Replicates the virtual machine to an EBS volume
  • Creates an EBS snapshot of the EBS volume called a DR copy in your AWS account
  • Deletes the EBS volume
Failover

The Phoenix AWS proxy replicates the entire virtual machine the first time it creates a DR copy. Subsequently, it incrementally updates the DR copy based on the replication frequency specified in the DR plan. This DR copy replaces the copy that is present in your AWS account.  Phoenix AWS proxy maintains only the latest DR copy of a virtual machine. At the time of failover, the Phoenix AWS proxy:

  • Converts the available DR copy to an EBS volume
  • Injects drivers into this EBS volume that is required to boot up the EC2 instance
  • Starts the EC2 instance, in turn spinning up to production in minutes
Failback You can failback the EC2 instances (failed over) and recover the virtual machine with a single click in your virtualization infrastructure in a few hours after it has been recovered to your AWS account during failover.

The following diagram depicts the Phoenix DRaaS workflow:

DR Failback Workflow.png

Restore workflow

Let's discuss the DR restore workflow flow briefly and know what is happening during the process of copying data from Druva account to the customer account.

DR_overview.jpg

  1. The Phoenix Cloud tells the Phoenix AWS proxy to copy the virtual machine backup data from S3 bucket in Phoenix.
  2. The Phoenix AWS proxy then makes an API call to execute this command. 
  3. The data from S3 goes through the Phoenix AWS proxy to the EBS volume and the data path for this Phoenix AWS proxy is the Internet gateway.
    We introduce one more entity here, which is S3 endpoint. It ensures that the data coming from one account to another does not leave the AWS network.
  4. Once the data has been copied to the EBS volume, then through another API call, the Phoenix AWS proxy creates an EBS snapshot of the volume and deletes the volume itself.

Failover workflow

To ask what a failover is, is to ask what happens when disaster strikes and the primary data center becomes unavailable. Here’s what happens.

DR_failover.jpg

  1. First, an administrator triggers the failover from the Phoenix Management Console and Phoenix Cloud instructs the Phoenix AWS proxy to initiate the failover.
  2. The EBS snapshot is used to create an EBS volume. The Phoenix AWS proxy creates an EC2 instance in your AWS account. You can choose the EC2 instance type from the Phoenix Management Console when you configure the VM for DR. The EBS volume gets attached to the EC2 instance.
  3. Once the process has completed, EC2 instance is restarted and is ready to support its workload. The same process is repeated for all protected VMs. 
  4. The last step is to update the DNS servers to redirect the traffic to the IP addresses of the new EC2 servers.

Phoenix provides advanced orchestration capabilities allowing to decide on the failover sequence, creating dependencies between EC2s and adding scripts for execution during EC2 boot. An example of dependency would be an e-commerce Web server storing data in the database. It wouldn’t make sense to start Web EC2 before the database is available.

Druva DRaaS also allows for DR testing in a different VPC or subnet. 

Failback workflow

The starting point for failback is a freshly rebuilt primary data center and backup DR site containing data which needs to be transferred back to the primary site.

DR_failback.jpg

  1. The first step is to redeploy the Phoenix backup proxy VM to establish communication with the Phoenix Cloud and get the backup configuration from the cloud. 
  2. In the next step, the backup proxy launches a template VM, which reaches out to the EC2 instance and get its configuration information – number of CPUs, memory size, number of disks, and so on. 
  3. Based on this information received, it attaches one or more VMDK disks and starts copying data from the EBS volumes to the VMDK disks. 
  4. Once the download is completed, the template VM is rebooted with the configuration parameters read from the EC2 instance. After that, the server is operational. The same process is repeated for all protected VMs. 
  5. The last step is to update the DNS to redirect the traffic back to the primary site.

 

Phoenix AWS proxy setup workflow 

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

 Phoenix AWS proxy is an Elastic Compute Cloud (EC2) instance that runs the Phoenix disaster recovery service. It orchestrates copying data from the Phoenix Cloud to your AWS account and creates a DR copy at a frequency specified in the DR plan. The Phoenix AWS proxy runs in your AWS account. The Phoenix AWS proxy is launched in the same AWS region where the virtual machine backups are located. The EC2 instances are started in the same region for disaster recovery.

Phoenix AWS proxy setup workflow

You must first select the AWS storage region on the Phoenix Management Console and create an AWS CloudFormation stack to define the AWS resources. Phoenix uses AWS CloudFormation to automate the current manual proxy deployment processes. It also includes the prerequisites of proxy deployments, such as the creation of IAM policy and IAM role, creation of IAM instance profile, security group, and attaching the policy to the proxy, deploy proxy by registering and activating the proxy.

AWS CloudFormation provides a simple JSON-based template to define all the AWS resources that you need to deploy your infrastructure for disaster recovery and a stack to create and manage the resources. For more information, see AWS CloudFormation Concepts.

The following diagram depicts the workflow to set up the Phoenix AWS proxy and the corresponding portals to perform the setup.

Quick steps to set up proxy1.png

Steps to set up the Phoenix AWS proxy

Step 1: Select the AWS storage region

Select the AWS storage region on the Phoenix Management Console where you want to deploy the Phoenix AWS proxy for disaster recovery.

Step 2: Click the Create CloudFormation Stack button

Click the Create CloudFormation Stack button on the Register Phoenix AWS Proxy page to configure your AWS resources. You are redirected to your AWS account.

Step 3: Log in to your AWS account
Log into your AWS account to define the AWS CloudFormation stack parameters.
Step 4: Create AWS CloudFormation Stack
  1. Define Phoenix configuration parameters
    Select one of the deployment template options, such as InfraAndProxyDeployment or ProxyDeployment, to deploy the IAM policies, roles, and proxy instances in your AWS account.
  2. Define Network configuration parameters
    Select the VPC and subnet specific to your AWS account to launch the Phoenix AWS proxy.
  3. Define AWS EC2 configuration parameters
    Select a type for the AWS proxy instances and an EC2 key-pair to enable SSH access to the proxy instance. Depending upon your subnet settings, select the Auto-Assign public IP option as true or false.
  4. Review and create the stack
    Validate the parameters selected and click Create to create the stack.
Step 5: View the deployed proxy
On the Phoenix Management Console, select your organization and click Disaster Recovery > Phoenix AWS Proxies tab, and view the deployed proxy on the Phoenix AWS Proxies tab.

Data backup with CloudCache deployment workflow 

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

The following diagram illustrates how data flows during backup in a Phoenix CloudCache deployment.

CloudCache_BackupFlow.png

Step Description

Step 1

 

Phoenix agent backs up the server data according to the schedule defined in the backup policy. At the scheduled time, Phoenix Cloud initiates the backup request and forwards it to Phoenix agent.

Note: Phoenix CloudCache maintains a persistent connection with Phoenix Cloud.

Step 2

 

  1. Phoenix agent backs up the data to Phoenix CloudCache.
  2. Phoenix agent saves the metadata to the storage that Phoenix Cloud assigns for backup.

Step 3

 

As per the predefined schedule, Phoenix CloudCache synchronizes the backup data to the storage that Phoenix Cloud assigns. 

Note: Phoenix CloudCache establishes an on-demand connection with cloud storage. After a synchronization is complete, the connection with Phoenix Cloud storage is terminated. For the next synchronization operation, Phoenix CloudCache establishes a connection with the cloud storage that Phoenix Cloud assigns. 

Note: Administrators must configure the synchronization schedule and a bandwidth that Phoenix CloudCache can consume. For more information, see Configure Phoenix CloudCache.

Data restore with CloudCache deployment workflow

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

The following diagram illustrates how data flows within the Phoenix setup at the time of hot restore.

cloudcache_restore_workflow1.png

Step Description

Step 1

Phoenix Cloud initiates the restore request and forwards it to the Phoenix agent.

Step 2

 

  1. Phoenix agent fetches the metadata from the storage in Phoenix Cloud.
  2. Phoenix agent queries the Phoenix CloudCache to restore the data.

Note: If the connection to CloudCache is interrupted at the time of a backup, the Phoenix agent backs up data directly to the Phoenix Cloud. Since the deduplication data is available on the Phoenix Cloud, Phoenix agent requires a connection to Phoenix Cloud and CloudCache to restore data. Ensure that the Phoenix agent can connect to Phoenix Cloud and CloudCache. 

Ports and communication protocols for VMware

Phoenix communicates with your virtual infrastructure to backup and restore virtual machine data. This communication happens via ports and communication protocols that are secure for communication and transition of data.

Phoenix uses a combination of Transport Layer Security (TLS) and Secure Socket Layer (SSL) protocols for establishing a connection and initiating communication between Phoenix components and your virtual infrastructure components such as vCenter Server, ESXi hosts, and virtual machines.

The following diagram depicts the ports and communication protocols that are used by Phoenix for secure connection and communication during the backup and restore operations.

port_communication_protocols_vmware_with_SQL.png

The following table describes the port and communication protocols used for communication between Phoenix and various VMware components.

Port

Communication Protocol

Description

443

HTTPS+SSL

Phoenix uses Port 443 to establish a secure connection and communication between the following:

  • Backup Proxy to Phoenix Cloud
  • Backup Proxy to Phoenix CloudCache
  • Backup Proxy to vCenter Server
  • Backup Proxy to ESXi host
    Note: Backup proxy establishes connection with ESXi host over Port 443 only if it registered with Phoenix as Standalone ESXi. If the ESXi host is registered with Phoenix through vCenter Server, backup proxy communicates with the ESXi host over Port 902.

902

TCP/UDP

Phoenix uses port 902 to establish a connection between the backup proxy and ESXi host registered with Phoenix through vCenter Server.

3542 HTTPS+SSL For application-aware backups, the backup proxy uses VMware Tools to inject two executables and a few supporting files such as certificates into the guest OS of the virtual machine. When the executables run, they start guest OS processes called guestossvc and PhoenixSQLGuestPlugin. The backup proxy uses the opened port 3542 on the guest OS so that it can communicate with guestossvc to run SQL Server backups. Ensure that this port is open on the guest OS.

The backup proxy also uses this port to restore databases to the virtual machine.
3545 HTTPS+SSL For application-aware backups, the SQL executable service PhoenixSQLGuestPlugin  queries the Microsoft VSS APIs to back up and restore SQL Server databases. The guestossvc service interacts with the PhoenixSQLGuestPlugin  service using this port. The PhoenixSQLGuestPlugin service cannot directly communicate with the backup proxy. 

3389/22

 

TCP/UDP

During the backup cycle, the backup proxy sends network packets to Windows virtual machines (where VMware tools are installed) on port 3389 to identify if the RDP port is open or not. For Linux virtual machines, the port is 22, which is used for SSH.

This is used for Phoenix DRaaS or DR restores.

123 UDP Backup proxy accesses NTP server on Port 123 (UDP) for time synchronization.

443

HTTPS+SSL

Phoenix uses SSL for a secure connection that happens between the following:

  • Backup proxy and vCenter Server
  • Backup proxy and ESXi hosts

443

HTTPS+TLS

Phoenix uses TLS for a secure connection that happens between the following:

  • Backup proxy and Phoenix Cloud
  • Backup proxy and Phoenix CloudCache
  • Phoenix CloudCache and Phoenix Cloud

 

 

Ports and communication protocols for File server

Phoenix communicates with your File servers to backup and restores the data from your File servers. This communication happens through ports and protocols that are secure for communication and transition of data.

Phoenix uses Transport Layer Security (TLS) protocol for establishing a connection and initiating communication between Phoenix components and your File servers.

The following diagram depicts the ports and communication protocols that are used by Phoenix for secure connection and communication during the backup and restore operations.

port_and_protocol_for_file_server_setup1.png

Ports and communication protocols for Phoenix CloudCache

Phoenix communicates with your virtual infrastructure to backup and restore virtual machine data. This communication happens via ports and communication protocols that are secure for communication and transition of data.

Phoenix uses a combination of Transport Layer Security (TLS) and Secure Socket Layer (SSL) protocols for establishing a connection and initiating communication between Phoenix components and your virtual infrastructure components such as vCenter Server, ESXi hosts, and virtual machines.

The following diagram depicts the ports and communication protocols that are used by Phoenix for secure connection and communication during the backup and restore operations.

port_communication_protocols_vmware_with_SQL.png

The following table describes the port and communication protocols used for communication between Phoenix and various VMware components.

Port

Communication Protocol

Description

443

HTTPS+SSL

Phoenix uses Port 443 to establish a secure connection and communication between the following:

  • Backup Proxy to Phoenix Cloud
  • Backup Proxy to Phoenix CloudCache
  • Backup Proxy to vCenter Server
  • Backup Proxy to ESXi host
    Note: Backup proxy establishes connection with ESXi host over Port 443 only if it registered with Phoenix as Standalone ESXi. If the ESXi host is registered with Phoenix through vCenter Server, backup proxy communicates with the ESXi host over Port 902.

902

TCP/UDP

Phoenix uses port 902 to establish a connection between the backup proxy and ESXi host registered with Phoenix through vCenter Server.

3542 HTTPS+SSL For application-aware backups, the backup proxy uses VMware Tools to inject two executables and a few supporting files such as certificates into the guest OS of the virtual machine. When the executables run, they start guest OS processes called guestossvc and PhoenixSQLGuestPlugin. The backup proxy uses the opened port 3542 on the guest OS so that it can communicate with guestossvc to run SQL Server backups. Ensure that this port is open on the guest OS.

The backup proxy also uses this port to restore databases to the virtual machine.
3545 HTTPS+SSL For application-aware backups, the SQL executable service PhoenixSQLGuestPlugin  queries the Microsoft VSS APIs to back up and restore SQL Server databases. The guestossvc service interacts with the PhoenixSQLGuestPlugin  service using this port. The PhoenixSQLGuestPlugin service cannot directly communicate with the backup proxy. 

3389/22

 

TCP/UDP

During the backup cycle, the backup proxy sends network packets to Windows virtual machines (where VMware tools are installed) on port 3389 to identify if the RDP port is open or not. For Linux virtual machines, the port is 22, which is used for SSH.

This is used for Phoenix DRaaS or DR restores.

123 UDP Backup proxy accesses NTP server on Port 123 (UDP) for time synchronization.

443

HTTPS+SSL

Phoenix uses SSL for a secure connection that happens between the following:

  • Backup proxy and vCenter Server
  • Backup proxy and ESXi hosts

443

HTTPS+TLS

Phoenix uses TLS for a secure connection that happens between the following:

  • Backup proxy and Phoenix Cloud
  • Backup proxy and Phoenix CloudCache
  • Phoenix CloudCache and Phoenix Cloud