File level recovery from Linux md-raid

[tm7]

Is it possible to have a file level recovery from disks, that are in an md-raid1 array?

[ronnmartin61]

Yes. File-level recovery (as far as I'm aware) isn't in any way dependent on the underlying RAID config...

[Andreas Neufert]

Hi Thomas, please clarify, do you use Linux Software Raid capabilities?

[mack3457]

Oh, sorry for the late reply.

Yes, I have one virtual machine with two 400 GB disks with RAID1 by mdraid.

[HannesK]

Hello,
I tested it and I would use instant VM recovery and manually copy whatever you need.

The file level explorer fails in such cases. The Veeam helper appliance has no error, but does not show the mountpoint. And with a helper host, I got "No such device. Failed to mount [linux_raid_member] file system"

But it's not documented in the user guide. Please give me some time to clarify whether I ran into a bug or a limitation.

Best regards,
Hannes

[mack3457]

Yes, thanks.

It's an unsual case, as I need to restore some log files from the raid disk(s) in multiple generations of the backup.

As the machine includes another 500 GB disk, this is a really tedious task. 1.3 TB of disks and multiple restore points in time take a really long time to restore. But at least it works, which is fine.

[tm7]

Oh, I see, I have two accounts here (tm7 and mack3457), sorry.
Getting confused, when everything runs fine and only every some years a question arises...

[aj_potc]

I've run into a similar problem where file-level restore from the VBR (using the file explorer) doesn't work on a system using mdraid.

However, it should be possible to run the Linux agent and start the restore from there. You can choose which backup you want to mount under /mnt, and then copy the files needed from there. It's not nearly as elegant as using the VBR, but this should work.

[HannesK]

Hello,
yes, agent should also work. Or Instant VM recovery (as I mentioned above)

QA confirmed a limitation around FLR from mdraid. This limitation will be added to the user guide.

Best regards,
Hannes