Skip to main content

Azure Data Lake Storage Architecture for Public Network Access

Druva provides a cloud-native architecture for protecting Azure Data Lake Storage without requiring customers to deploy or maintain permanent backup infrastructure. The architecture separates the customer’s production environment from Druva’s data-processing and backup-storage environments.

Druva uses a service principal, an App Secret, and a custom Azure backup role to access the selected ADLS resources. An ephemeral, on-demand Data Mover transfers data between the customer’s ADLS storage and the Druva Resilience Cloud during backup and restore operations.

Components in the customer environment

The following components reside within the customer’s Microsoft Azure environment.

Customer Entra ID Tenant

  • Service Principal: Provides the application identity that Druva uses to authenticate with Microsoft Azure.

  • App Secret: Provides the credential associated with the service principal.

Customer Subscription

  • Custom Backup Role: Grants the permissions required for Druva to access and protect the selected ADLS resources.

  • Azure Key Vault: Securely stores the App Secret used to authenticate Druva operations.

  • ADLS Storage: Contains the production data selected for backup and recovery.

Components in the Druva environment

The following components are hosted and managed by Druva.

Druva Subscription

  • On-demand Data Mover: Druva provisions this ephemeral service when it is required for a backup or restore operation, for publicly accessible Storage Accounts.

  • Region-matched processing: Druva provisions the Data Mover in the same Azure region as the Storage Account to eliminate egress charges for data transfers between the source storage account and the Data Mover.

  • Elastic scaling: The Data Mover scales according to the ADLS data being processed and is optimized for cost-efficient data movement.

Druva AI Resilience Cloud

  • Druva-managed storage: Druva stores the protected data in Azure Storage or AWS Storage within the Druva AI Resilience Cloud.

Backup workflow

  1. Druva authenticates with the customer’s Microsoft Entra ID tenant by using the configured service principal and App Secret.

  2. The custom backup role authorizes Druva to access the selected ADLS resources in the customer subscription.

  3. Druva provisions an on-demand Data Mover in a region-matched Druva subscription.

  4. The Data Mover reads the selected data from ADLS storage.

  5. The data is transferred from the customer subscription to the Data Mover without incurring egress charges for the customer.

  6. Druva transfers the protected data to Druva-managed Azure or AWS storage in the Druva AI Resilience Cloud.

Restore workflow

  1. An administrator initiates a restore and selects the required recovery point and destination.

  2. Druva provisions an on-demand Data Mover in the same region as the target Storage Account.

  3. The Data Mover retrieves the protected data from Druva-managed Azure or AWS storage.

  4. The Data Mover transfers the recovered data to the selected ADLS destination.

  5. The transfer from the Data Mover to the customer subscription does not incur egress charges for the customer.

Isolation and security

The customer’s ADLS environment and the Druva AI Resilience Cloud reside in separate Microsoft Entra ID tenants, and separate Azure subscriptions and security boundaries. This separation provides a logically air-gapped architecture that helps isolate backup data from security incidents affecting the customer’s production environment.

Druva manages the Data Mover and backup storage, while the customer retains control of the ADLS resources and access configuration within their Azure environment.

Did this answer your question?