❗ Important
File Level Search and File Level Restore are currently not supported directly from Druva Cloud. You will first have to restore the AMI snapshot and then proceed with File Level Search on the new snapshot.
Druva CloudRanger’s granular search feature can prove to be invaluable when recovering files that have been accidentally deleted or lost due to migration errors. You can use this functionality to recover files that may have been deleted, or to confirm whether a file exists, as part of compliance and governance.
📝 Note
File Indexing is an optional setting that can be enabled from your Account Settings page. The indexing settings will help define the accuracy of file search within backups. A higher indexing frequency will ensure accurate search results, while also impacting costs.
Before you Begin
The File Level Search feature is optional and will need to be enabled from your Account Settings page.
Log into your management console and navigate to the account on which you wish to enable file search.
Click the Settings icon on the left navigation menu and navigate to File Level Search Settings to enable File Indexing.
Enable File Indexing. You may also set the Backup Index Options to Index all backups on Druva CloudRanger.
📝 Note
File Level Search feature when enabled will create an S3 Bucket per user account to store the file system metadata of the target backups. The CloudFormation scripts may need to be updated to allow access to the S3 bucket.
Perform File Level Search
Step 1: Execute Backup Policy and Index for Search
Once File Search is enabled, you can execute a backup policy and then choose to Index specific backups for File Search.
Log into your management console, navigate to Resources and select the Backups tab.
Select the backup to be indexed and click Index for search.
📝 Note
The file icon remains grey prior to indexing of a backup. Once the backup is complete and indexed to make it searchable for files, the file icon changes to blue.
3. Click the blue file icon to be redirected to the File Search page.
Druva CloudRanger automatically enters the snapshot selected into the In Backups textbox. You can specify other search criteria, as relevant before initiating search.
Step 2: Browsable Indexed Snapshots
Navigate to File Search from the left navigation menu.
Specify the search criteria such as File Type, File Size, Date modified, or initiate search within a specific Resource or Backup.
Click Search.
Step 3: Retrieve File from Search Results
Once the target file(s) have been identified, the Search Results displays the files within the backup versions that match the criteria specified.
Select the file and click Retrieve files, and then click Start File Retrieval.
Alternatively, click the link under Versions to download the files.
This initiates the download of the selected file to the user’s desktop.
Frequently Asked Questions
What are the minimum Security Group rules (inbound and outbound) required for the FLS index instances to function?
What are the minimum Security Group rules (inbound and outbound) required for the FLS index instances to function?
Ensure that the Security Groups do not block access to the S3 Buckets. You can locate the S3 Bucket created for FLS within the Account Settings for each AWS Workloads (CloudRanger) account under the FLS Network Settings section.
How are the Security Groups selected for the FLS Index job?
How are the Security Groups selected for the FLS Index job?
AWS Workloads (CloudRanger) uses the run-instances AWS command to run the indexer. If a Subnet is selected under the FLS Network Settings, then the VPC corresponding to this Subnet is chosen to launch the Indexer Instance in. The Security Groups are then selected in one of the following ways:
If a Security Group within the selected VPC has the tag key ‘druva_cr_fls_sg’, then these are attached to a NetworkInterface for the run-instances call.
If there are no Security Groups with this tag, the run-instances AWS command will attempt to use the default Security Group, if applicable.
Why are volumes or folders not showing for Linux VM backup while doing FLR?
Why are volumes or folders not showing for Linux VM backup while doing FLR?
File indexing of EBS volumes and FLR with LVMs on Linux is not supported, This is limitation of Cloud ranger as well as AWS.
Challenges with LVM at the Virtualization Layer:
AWS Backup primarily interacts with virtual disks, similar to Druva CR operating at the Virtualization layer (e.g., EBS volumes for EC2, VMDKs for VMware).
The LVM configuration resides within the guest operating system. Without direct OS access during a typical virtualization-layer backup, the backups do not inherently capture or parse the LVM metadata (like LVM config files
/etc/lvm/) to enable seamless FLR across all LVM configurations.Simple LVM setups, such as a single LVM volume on a single virtual disk that directly maps to a standard file system like ext4 or XFS, might be more amenable to FLR if the underlying file system is recognized.
How AWS and Druva handle restores:
Full Volume/Instance Restore: For complex LVM setups, the most reliable method with AWS Backup (and similar virtualization-based backup solutions) is often a full volume restore or an entire instance restore. After restoring the volumes, the guest OS would then reassemble and recognize its LVM configuration.
EBS Snapshot Restore for FLR (Manual Process): If you have EBS snapshots (which AWS Backup can manage for EC2 instances), you can manually achieve a form of FLR even with LVM:
Restore the EBS snapshot to a new EBS volume.
Attach this new volume to a running EC2 instance (either the original or a temporary one).
Within the OS of that instance, you'd then need to make the OS recognize the LVM structures on the attached volume (e.g.,
pvscan,vgscan,lvscan,vgchange -ay).Once the logical volumes are active, you can mount them and copy the required files. This process requires OS-level commands and understanding of your LVM setup. It's not an automated FLR in the same way as it might be for a simple, non-LVM volume.