Q: Why do I need backup if Azure already provides replication?
A: Azure provides availability (your data is replicated across regions and survives hardware failure) but NOT protection against:
Accidental deletion
Ransomware/encryption attack
Application bugs that corrupt data
Malicious insider modifications
Regulatory compliance requirements (data retention)
Druva backup protects against these scenarios by storing immutable copies in a separate cloud location, preventing attacker access even if they compromise your Azure account.
Q: Are Azure RBAC role assignments restored along with file-level POSIX Access Control Lists (ACLs)?
A: No. Only POSIX ACLs are restored — Azure RBAC role assignments are not backed up or restored by Druva. RBAC role assignments must be manually reapplied post-restore in the Azure portal or via Azure CLI. However, if you use POSIX ACLs for access control instead of RBAC, they will be preserved during restore (within the same tenant; they are stripped for cross-tenant restores).
Q: Why does the initial baseline backup take significantly longer than subsequent jobs?
A: The initial full backup must scan and capture all data in the storage account from scratch. Subsequent backups are incremental—they only process data that has changed since the last backup using change detection, making them significantly faster. The ADLS Support Matrix confirms incremental backup with change detection is supported, but specific performance benchmarks by dataset size are not documented.
Q: How long does a typical restoration job take based on dataset size and file counts?
A: The ADLS Support Matrix does not document typical restore duration by dataset size or file count. For specific performance benchmarks and restore time estimates, contact Support.
Q: How does backup protection impact storage account performance during backup operations?
A: The ADLS Support Matrix does not document the performance impact of backup operations on storage account performance. For information about performance overhead, I/O impact, or recommendations for minimizing performance effects during backups, contact Support.
Q: How are backups encrypted and secured in transit and at rest?
A: Backups are encrypted in transit using TLS (HTTPS). At rest, backups are encrypted and stored independently from your source storage account. Both Microsoft-Managed Keys and Customer-Managed Keys (CMK) are supported for encryption. Specific encryption algorithms and key management details are not documented in the support matrix; contact Support for technical specifications.
Q: Can an attacker modify or delete backups if the primary Azure tenant is compromised?
A: No — backups are protected by air-gap and immutability controls. Once a backup snapshot is committed, it cannot be modified or deleted by automated processes, even if an attacker compromises your Azure tenant. The attacker would lack Druva credentials and cannot access backups stored independently in Druva's cloud. However, whether a Druva administrator can manually delete backups and under what conditions requires confirmation from Support.
Q: How does cross-tenant recovery work during an isolated recovery or ransomware event?
A: You can restore ADLS backups to an isolated, new Azure tenant for forensic analysis and cyber recovery. Data is recovered intact; however, POSIX ACLs are not preserved (data-only restore), and files inherit default permissions from the destination filesystem root. A warning dialog is shown in the UI. After cross-tenant restore, you must manually reapply ACLs in the destination tenant. This protects against ransomware that compromises your production tenant by providing a clean recovery environment.