Centralized cloud backups have simplified compliance while reporting and alerting still need workThere are significant disadvantages that need addressing. Failure reports are limited. Alert notifications for Druva inSync, Druva endpoints, and Druva M365, which are managed by backup profiles, cannot be configured to send automated or real-time alerts. We have to depend on manual checks and go to the console directly. I had a customer who recently purchased Datadog. Even when filtering the logs, we see many "backup completed with errors" messages. However, when I go to the console, I cannot find anything. After researching, I discovered that backups showing as never backed up could involve many users or workloads that have not yet been backed up. They might be new joiners where backup has not started or has not been configured. However, since they were added to Azure AD, Druva provisioned them through the user provisioning process. If they have never been backed up, the system shows them as backed up with errors, which is disappointing. Druva's argument is that they want to flag them as errors because they have never been backed up, but customers should not be bothered by workloads that have not been backed up. Reporting is another area where we are really struggling. If we need three months of data, we cannot get that report. We have received many requests from customers asking for reports showing backup frequency. For example, if backing up five times a day, they want a report showing exactly how many times it is actually getting backed up. There is no way to see that report. When downloading the last user backup status report or rollout report, we cannot see a single entry for all five backups for that particular endpoint. There is no way to tell customers that a backup is running five times a day and will generate five snapshots unless we manually visit each client and check the backup schedules. Those reporting limitations are really disappointing. Documentation is not concise and clear. One of our clients got downsized and decommissioned everything due to compliance requirements. Some companies cannot pass FDA licenses and certifications, so they downsize and lay off staff. This client stopped their on-premises DFS file share in Windows and moved to Azure. We configured Druva Data Security Cloud backup for Azure file share, which completed successfully. During the cleanup process, the Azure team saw many keys in Azure Key Vault, deleted those keys, and performed a soft delete. The moment they did the soft delete, backup started failing. I worked with support, but Druva support had no idea because it was not documented anywhere that Quantum Bridge VM requires Azure Key Vault services for private machines or private shares behind private subnets not exposed to the public internet. Support searched logs, took extensive logs, and checked with the engineering team. It took around ten days to resolve the issue. They found that because the Azure team deleted the keys from Key Vault, the Quantum Bridge VM provisioned in the private subnet could not connect to the public internet, and therefore provisioning failed. However, this is not documented in Druva documentation. I also received a request for AWS FSx backup for NetApp ONTAP. I searched and could not find any documentation. I was forced to create a ticket with Druva support. We have a CSM, and since we newly bought Druva Cloud Ranger, Druva appointed a CSM for this. I sent an email, and the CSM said they are looking internally, but externally or as a Druva user, I cannot find any documentation. These things are very disappointing and should not happen with an enterprise backup tool.
