AWS Backup’s New Search and Item-Level Recovery

A step forward, but not quite file-level recovery, not quite free, and not quite instant!

Not to mention… not very secure.

AWS Backup recently announced a new feature: support for search and item-level recovery for Amazon EBS Snapshots and Amazon S3 backups. This new capability allows users to search through the metadata of their backups and recover individual items without restoring an entire backup. It’s designed to make recovery times faster and more efficient, but is it really as seamless and user-friendly as file-level recovery? Let’s take a closer look.

What AWS Backup’s search and item-level recovery feature offers

AWS claims that they make searching and restoring specific files simpler, and faster. Essentially, AWS users can search their Amazon EBS Snapshots or Amazon S3 backups for a file, whereas before, you had to restore and manually explore the entire EC2 instance for the file you wanted.

How does the new feature work? The user has to create a “backup index,” which is essentially an index of the backup metadata. The index must be built, and then you can search your backups to find specific files or objects across multiple backups. You can also search based on various filters, such as file or object names, creation times, sizes, or even more granular attributes like Amazon S3 object versions.

Once you’ve located the specific file you need, you can restore them directly to an Amazon S3 bucket, rather than performing a full backup restore.

The idea behind this is simple: rather than going through the trouble of restoring entire backups to get to specific files, you can locate and recover just the files you need, all from the AWS Backup console, API, or CLI. This should theoretically lead to faster recovery times for situations where you need only a few files rather than an entire backup.

But there’s a few catches

1. It’s not exactly file-level recovery

While AWS Backup’s new feature is useful, it isn’t the same as true file-level recovery. This is because traditional file-level recovery allows users to directly recover specific files from a backup without having to go through any pre-indexing process.

There are several disadvantages to pre-indexing that can cost you precious time, effort and security.

AWS Backup’s item-level recovery not only requires an extra step of creating a backup index, it isn’t full-proof. For example, if your search wasn’t specific enough and doesn’t match your pre-indexing naming convention, you may have multiple matches (or none) and you’ll restore more than you’ll need to find your file.

And what about if you simply didn’t index the file like you thought you did? Or failed to index the latest version of your file? The pre-indexing process itself requires constant manual updates and human intervention to ensure that the latest and most critical files have indeed been included in the index.

This all starts to look like trying to find that rock you saw on the beach yesterday. AWS Backup’s additional indexing step requires both additional time and resources that are error prone, leading to a false sense of security regarding data accessibility and searchability.

2. There’s a cost to pre-index and restore

Another point to consider is the cost involved in both creating a backup index and searching and restoring what you need. Not only does each backup index incur a fee (this is in essence a storage charge), each restore from your search result has additional charges.

This means that if you’re looking to use the search functionality regularly, you will need to can accumulate costs related to both indexing and restoring your backups. This can add up depending on the volume of data you’re managing, and the complexity of your procedure.

Pricing for AWS Backup’s New Search and Item-Level Recovery:

3. There are restore limitations

AWS Backup currently limits the number of indexes that can be restored at the same time to five. This is even across the various methods of initiating a restore (AWS Backup console, API or CLI). 

Limited indexing can be problematic. It leads to a multi-step, fragmented recovery process which can compromise business continuity. When numerous files are lost due to cyberattacks or outages, multiple restore operations dramatically increase RTO. This fragmented approach not only disrupts supply chains, it undermines customer confidence and can lead to severe reputational damage.

Chaos and multiple initiations in our disaster recovery process? No, thanks.

Tips from the Expert

Sebastian Straub

Sebastian is the Principle Solutions Architect at N2WS with more than 20 years of IT experience. With his charismatic personality, sharp sense of humor, and wealth of expertise, Sebastian effortlessly navigates the complexities of AWS and Azure to break things down in an easy-to-understand way. Connect on LinkedIn

Linkedin

• Use Lifecycle Policies to Save Money: Set up lifecycle policies to move old backups to cheaper storage options like Amazon S3 Glacier. This can help you save a lot of money on storage costs.
• Back Up to Different Regions and Accounts: Make your disaster recovery plan stronger by copying backups to different AWS regions or accounts. This protects your data from region-specific problems and security issues.
• Automate Your Backup to Reduce RTO: Use AWS Backup to set up frequent backup intervals. Automating backups every hour or even every few minutes ensures you can recover data quickly, minimizing downtime.
• Tag Your Resources for Easy Management: Tags help you quickly identify and group related backups, making it easier to manage them and to monitor costs. This can also simplify reporting and compliance checks.
• Test Your Disaster Recovery Plan Regularly: Automate DR drills to check your backup and recovery processes. Make sure your backups work and that you can restore data quickly to find and fix any potential problems.

4. There are security issues

Besides requiring extra time and money, keeping an index in your cloud environment runs a security risk. The moment you create an index, that index becomes an attack surface for bad actors. Them merely knowing that the file exists, or what the file name is, or where the file is located  –  is a security issue.

By indexing your backups, you inadvertently provide attackers with valuable information about the existence, location, and naming conventions of sensitive files and objects.

How It compares: N2W vs. AWS Backup

Let’s compare AWS Backup’s new feature to N2W, our cloud-native backup and disaster recovery solution for AWS and Azure:

• Indexing Requirement: AWS Backup’s feature requires pre-indexing before you can search for and recover specific files. This adds complexity and cost. N2W, on the other hand, does not require indexing and allows you to recover individual files directly from your backups without any setup whatsoever.
• Recovery Time: With AWS Backup, after the index is created, you can search for and restore specific files. However, if you haven’t indexed your backup, or if the index is outdated, the recovery could take longer. N2W ensures that you can recover files quickly and directly without the need for indexing or additional steps. You can even conduct scheduled and regular DR drills for peace of mind, ensuring you will have quick access to all critical files in the case of data loss.
• Costs: AWS Backup’s feature incurs additional costs for indexing and searching. In contrast, N2W offers file-level recovery without these extra charges, making it a more cost-effective option for businesses looking for a straightforward backup and recovery solution.
• No Restore Limitations: While AWS Backup restricts simultaneous restores to just five indexes regardless of the restore method, N2W enables seamless, multi-file recovery without any constraints. You can recover as many files as needed without any multiple, fragmented restore steps, thereby maintaining optimal businesses continuity with minimal RTO.
• Much Safer: True file-level recovery without an index presents a much safer alternative than pre-indexing. Because you are no exposing all of your indexing data, you minimize potential attack surfaces. With N2W this does not require manual effort and even more than that, N2W has no access to any data. The reason why many government loves us, is that N2W doesn’t know what they’re backing up. We do not keep a record and we intentionally do not create an inventory index, to keep the bad guys guessing. We allow for file level recovery ad-hoc without the need to compromise your security stance.

Conclusion

While AWS Backup’s search and item-level recovery feature is a step in the right direction for improving restore, let’s face it. It isn’t set up to simplify the life of your backup IT admin and introduces additional costs that businesses won’t be keen to take on.

For those looking for a quick, truly granular, cost-effective solution, file level recovery (FLR) using N2W remains the champion. By the automating the entire process of accessing metadata within an instance, backup teams can rest easy.

And trust us, we’ve seen it all – customers rescued from mistakenly deleted files and the wrath of their bosses. Files appear, no indexing required, no hidden fees, no need to learn ancient incantations.

Because remember, in the world of data recovery, it’s all about being the hero and being able to have that coffee break. And with N2W, you’ll definitely have both.

Test drive N2W File Level Restore to see the easiest and quickest file and folder level recovery for your environment, and if needed even restore from your S3 repository.