Extract tool with file level support

[akhon]

Hi,

The extract tool is a must have when a disaster comes. However, the current tool has a very frustrating problem: It can only restore full VMs. And when you want only to extract (off-shore) small configuration files, then this is a pain. Therefore I suggest to add some file level options. For example this is the current -help:

Code: Select all

 Usage:

  extract.exe [-password backupkey] [pathtobackup]
    - Interactive restore mode

  extract.exe -help
    - Prints this help

  extract.exe -dir [-vm vmname] [-host hostname] [-password backupkey] pathtobackup
    - Enumerates VMs in the backup file

  extract.exe -restore [-vm vmname] [-host hostname] [-password backupkey] pathtobackup [outputdir]
    - Restores all or selected VM from the backup file

  extract.exe -getEncryptionStatus pathtobackup
    - Retrieves the encryption status of the backup file

The you can add these two actions:

Code: Select all

  extract.exe -listfiles [-vm vmname] [-host hostname] [-password backupkey] pathtobackup
    - List all files in the backup file

  extract.exe -extractfiles [-vm vmname] [-host hostname] [-password backupkey] pathtobackup files [outputdir]
    - Restores the selected files (with wilcards) from the backup file

With this extension it will be more easy to extract the configuration files.
You agree?

[HannesK]

Hello,
and welcome to the forums.

The "extract tool" for your use-case is Veeam Backup & Replication Community Edition. It works without license and can do most restores. Extracting files from a vm-based / block-based backup is a bit more complex than adding some parameters to a few MByte tool

Best regards,
Hannes

[akhon]

Hi HannesK,

I don't understand the use-case: every version of Veeam Backup & Replication (CE or not) includes the "extract" tool.

Regarding the complexity of the functionality... The first question is: How to LIST the content of the VM backup file? Perhaps you think this is trivial, but if your backup has a very large virtual disks, then you need the same space to "unpack" (aka restore) from the backup. And only to see the files inside it. This is not the best solution. Futhermore, I can't imagine what is the complexity to add this functionality to this tool. The second point is: How to EXTRACT only specific files? Here perhaps it could be more complex... in case of the command line. For this could be best to implement the funcionality in the GUI tool. It will be easy: the user selects the files, and the tool extract these files.

I'm sure that a lot of users will be happy if this functionality will be integrated. Don't you think so?

[david.domask]

I think that's what Hannes is trying to say, @akhon, it's not that it wouldn't be useful, but it's a fairly complex feature for what is meant as a "last ditch" effort restore tool for absolutely critical situations.

Can I ask, is there a major benefit to using Extractor as opposed to spinning up a VM and installing Veeam? Yes it's longer than just cd'ing to a directory with Extractor, but you can install Veeam even on a Windows 10/11 machine and do the same fast restores with Powershell today.

[HannesK]

okay, maybe my wording was bad: for your use-case, please install Veeam Backup & Replication community edition. Then you can extract files.

doing what you ask for would end up in a second "Backup & Replication" with less buttons. That makes little sense to develop, because one can just install the full Backup & Replication.

[akhon]

Hi,

From the comments from David and HannesK I feel that some users think that the "extract" tool is innecessary and the best is to install B&R in any version. But sorry, I don't agree with that. My boss makes mandatory that ANY recovery could be done WITHOUT installing any tool. So the "extract" tool is the way to achieve this REQUIREMENT. However, the problem with this tool is that you can only do FULL restores. What I request is the option to go at FILE LEVEL with restore operations, and not only at VM LEVEL.

It's more clear now my request?

[HannesK]

Hello,
your request is clear. But it will not happen, because implementing file level recovery in a "standalone extract tool" would result in a fork of Backup & Replication.

We can agree to disagree. That happens from time to time

ANY recovery could be done WITHOUT installing any tool

then I recommend using rsync or any other file copy tools that saves the data in the original format.

If you like to continue using Veeam, then I would ask what is the reason for the requirement of having a "standalone tool" vs. "installed tool". The Veeam Explorers also require installation, so "ANY" restore would not work.

Best regards,
Hannes

[akhon]

Hi,

Perhaps it's true that a "standalone extract tool" would result in a fork of Backup & Replication. However, why not incorporate the functionality to LIST the files inside the backup? This will provide a more easy method for searching after a disaster. And regarding the convenience of a "standalone tool" for disaster recovering, it seems to me that you have not yet suffered a total disaster.

[Regnor]

Doing a fresh installation of VBR only takes about 30-60 minutes, and importing the backup files isn't complicated and time consuming at all.
This is really an advantage compared to other solutions, where you have to spend too much time recreating or importing an exisiting configuration.
And only with a running installation you'll be able to do VM or application restores. In a total disaster this is probably what you'll want to do, instead of a file level restore.

[LickABrick]

My usecase for a standalone tool with possibility of file level restores would be the following:

Certain customer requests a yearly backup to a USB disk, the disk is their ownership and they are responsible for storing this backup.
Let's say the disks contains information they need to store for 10+ years (which is the case for on of our customers). Currently they need to contact us if they want to restore a couple of files from this backup since they do not have knowledge about Veeam. We need to either setup a VBR server quickly, or take the disk to our datacenter, plug it in and restore from there. Both take quite a lot of time, and this time costs the customer money (this is of course not Veeam's problem but still).

Also what if:
- VBR version on 30 years does not support the old VBK format and cannot restore from there?
- The customer decided to use another IT company to manage their resources and they do not use Veeam
- Veeam does not exist anymore in X years (let's really hope this is not the case)

We could also include a VM file with the backup which contains a Windows installation with the same VBR version as the version the backup was taken on, but a seperate tool would be much easier. Especially since the customer is not really tech-savvy.

[david.domask]

Just my input @LickABrick, while I understand the concerns here, there are a few simple answers I suppose.

1. For the Low-Techknowledge customer, I'm not sure that the situation changes with FLR from Extract Tool or not; they still need to take the disk to you, and presumably you either have a VBR server handy or can deploy/destroy one pretty fast with templates. The restore can be done with Community Edition (read: Free as in beer edition), and I guess it could just be sitting and installed on even a workstation if it's just for restore purposes. It would be pretty much as simple as just import and you're good to go. Granted, that's an installation footprint which is sizeable compared to just Extractor, but Extractor is kind of designed as a "last resort" to get machines up and running again, not for occasional restores; it can be used that way for disks, but seems overkill.

2. Format compatibility is of course a pretty major concern; since I've been with Veeam, we've addressed issues in the product for restores from very early versions and there is a concentrated effort for ensuring the backwards compatibility for restores. (I think I remember we made a fix for some Instant Recovery to new Hypervisor for backups from v5 even). In short, I suspect this will be handled

3. In such a situation, I think that's on the Customer and the IT company to just install Community Edition.

4. Aha, let's all hope But I guess even if Veeam vanished tomorrow, the ISOs would still exist online and be usable.

I absolutely get what you're discussing here, and I still think that if it were me, I would just keep a copy of the Community Edition around. I'm not sure what your contractual agreements are with the customer, but I think if you simply consider any backup solution outside of simple rsync's of files, it's probably the same consideration (and with rsync you have the backup storage to consider and maintain).

I'm not dismissing the concerns here, I think they're great questions and considerations; from my perspective, they're actually just responsibilities that need a decision on who to delegate them to, and then that entity needs to ensure they're maintaining their data and a recovery plan. Backups shouldn't be just set and forget A backup without periodic restore tests is just data on a disk of questionable intention

[HannesK]

2. yes, we still restore backup files from version 1 and have no plans to drop backward compatibility

for long term, I also recommend to look at archiving. While we (and the whole backup industry) supports long retentions (because customers want it), it makes little sense to try archiving with a backup product. Of course, backup vendors like it, when customers commit to a software for 30 years... well Veeam gives them a chance to restore for free. Not everybody does that

[akhon]

Hi,

Thank you all for your comments. Anyway, I feel all of you're missing some key point: The "extract" tool exists. And this tool now runs in Windows and Linux. Therefore it's not necessary to discuss about the benefits of installing any B&R version to complete a restore action. Both options are valid. However, what you need to accept is that USERS (your customers) are who decide what is the best option to do it. As a developers you (Veeam) can decide what to implement inside your product. But you don't have the privilege to decide in which way the users require to use your product. Said that, I repeat it: MY REQUIREMENT IS A TOTALLY INDEPENDENT AND PROTABLE TOOL TO COMPLETE **ANY** RESTORE ACTION. And at time this tool exists. And I hope this tool will be maintained in the future. However, for CONVENIENCE it will be desirable to support inside this tool a FILE LEVEL selection, instead of the current only VM LEVEL. I'm sure that a lot of users will agree with this petition, because is reasonable and useful. Another question is if Veeam wants or not to support it.

Thank you.

[akhon]

Hi,

After some time discussing about this with my boss, our conclusion is this:

- For all VBK backups of "Virtual Machines" (not other type of backups), we will execute one script that will do this after the backup: execute the "extract" tool with the backup file to a temporally directory, and repack it with an standard ZIP tool. Then archieve the .ZIP backup to another shared storage. This will not break the Veeam Backup infrastructure, and enables the way to a full restore without the needed of any tool. However at the cost of nearly duplicate the backup space (not a real problem if you need to guarantee the availability of the backup).

Anyway, I hope that in the future you (Veeam) will reconsider the functionalities of the "extract" tool.
Regards.

[doktornotor]

repack it with an standard ZIP tool. ... enables the way to a full restore without the needed of any tool.

Uhm... I recall an ancient bug with particular chipsets and their storage drivers that caused particular file types to have some of its bits flipped when copying... Not even touching things like ACLs, timestamps, strange chars in file/directory names, symlinks, hardlinks etc.

Good luck.

Edit: This is a fancy example of definition of a "standard ZIP tool" - https://github.com/nextcloud/server/issues/2352