cgsecurity.org

I run a linux server on a 4 bay HPE Proliant Gen10 machine. Ran well for 3 years. My ubuntu server OS was installed on a USB flash disk which broke. Unable to restore, I finally decided to go for new USB flash disk (SanDisk USB 3.0 32GB) and installed ubuntu server 20.04.1

Here comes my stupid mistake: In setting up the server OS with my 2X 4TB (seagate ironwolf) HDD I decided to go for RAID1, which wasn't the previous setup. With the new setup I can't locate my old folder structure and files.

I cloned the HDDs! (had to buy 2 new 4TB drives). And now I am trying to get TestDisk to help me recover to the original state, but unfortunately It won't recognize any previous partition table (GPT EXT4) I presume. I can't recall honestly. Trying with MS data and Linux data files options, but then it says 'Can't open filesystem. Filesystem seems damaged' and won't list files or folders.

Tried out photorec, but unfortunately with a 4TB drive, it'd recover files (no filename on it) and it'd take up to 700 hours - close to a month. Can't afford that. There must be an easier way to recover old file structure????
Any help you can provide will be greatly appreciated. I've been tinkering for too long and am clueless.

HDDs are in good condition. No physical damages detected on any of the 4 4TB HDDs.

CoWoAdmin wrote: 27 Aug 2020, 13:04 I run a linux server on a 4 bay HPE Proliant Gen10 machine. Ran well for 3 years. My ubuntu server OS was installed on a USB flash disk which broke. Unable to restore, I finally decided to go for new USB flash disk (SanDisk USB 3.0 32GB) and installed ubuntu server 20.04.1

Here comes my stupid mistake: In setting up the server OS with my 2X 4TB (seagate ironwolf) HDD I decided to go for RAID1,

"to go for" does not really tell what you did.

which wasn't the previous setup.

Is this setup a secret?

With the new setup I can't locate my old folder structure and files.

I cloned the HDDs! (had to buy 2 new 4TB drives). And now I am trying to get TestDisk to help me recover to the original state

which is still hidden for all readers eyes.

It's kind of difficult to say anything smart if you don't tell what has been before and how you created your problem.

Apologies Recuperation,
I am not at all versed in forums. Will try to explain myself better:
1.) Bought a HW solution called MINEBOX to a crypto decntralized storage solution called sia (https://sia.tech/ if you are interested). I knew the founders and wanted to support them.
2.) The initial setup was Rockstor OS (http://rockstor.com/) on usb flash 3.0 and 2 4TB Seagate Ironwolf internal bay drives for data storage (Linux, btrfs) - I guess setup for redundant storage.
3.) I bought this already setup to plug in and start the decentralized storage solution (encrypted in the sia network - blockchain). Since MINEBOX was sold to ClearOS, the whole thing stalled.
4.) After a while not getting news or updates, I decided to take advantage of the HW with a Linux based file server with ubuntu 18.10. I can't recall the exact setup procedure, nor did I write it down, but it worked flawlessly for years. Here the issue is that I can't recall the FS setup. Since all my clients work on Linux, I didn't install SAMBA, nor did I use NTFS or similar. SO my guess is that either Ext4 or btrfs where used. I had my IP Cams recording surveillance videos and all accounting on that ubuntu file server (no GUI).
5.) The USB flash disk broke and the server started failing often. I couldn't recover from OS failure, so decided to install fresh 20.04.1 ubuntu server on new flash 3.0. This time around stupid enough to keep the 4TB disk in the bays and tell ubuntu to setup RAID1. My understanding is that the disks got formatted for RAID1 (MD127) and I lost all my files (the MINEBOX ones - irrelevant to me, since they where encrypted), but also the important ones form the ubuntu 18.10 setup that broke.
6.) Apparently HPE Microserver Gen10 sets up efi boot files by default on the HDD in bay 1. So, now when using Testdisk on the cloned drives I get FAT12, btrfs, Ext4, filesystems back (quick search), but I am not able to see the tree, folders or files. When going for deeper search just a few and most say when browsing 'filesystem damaged' (can share screenshots at request) - As a matter of fact the quick search doesn't return anything. The deeper search takes up more than 6 hours and returns some, but not what I am looking for.
7.) What confuses me a lot is that Photorec recovers a lot of the files (if not all) lost without (metadata, like name, date created or modified, etc...). The issue is that I can't be sure the files are complete and not stub, and the process would apparently take up to 50 days????

Let me know if you have further questions. Best regards from Vilanova i la Geltrú.

Cowoadmin

CoWoAdmin wrote: 05 Sep 2020, 11:50 6.) Apparently HPE Microserver Gen10 sets up efi boot files by default on the HDD in bay 1. So, now when using Testdisk on the cloned drives I get FAT12, btrfs, Ext4, filesystems back (quick search), but I am not able to see the tree, folders or files. When going for deeper search just a few and most say when browsing 'filesystem damaged' (can share screenshots at request) - As a matter of fact the quick search doesn't return anything. The deeper search takes up more than 6 hours and returns some, but not what I am looking for.

If looking into each file system proposed after running deep search using the "p"-key (list files function) does not recover what you are looking for use Photorec or some commercial software. As your accounting files are concerned you might consider using a professional lab which might have experience with recovering your particular file type.

7.) What confuses me a lot is that Photorec recovers a lot of the files (if not all) lost without (metadata, like name, date created or modified, etc...). The issue is that I can't be sure the files are complete and not stub, and the process would apparently take up to 50 days????

Do not run brute force mode in Photorec on your big drives. The loss of metadata and recovering broken files is caused by the way Photorec works. Photorec is the last line of defense against data loss. It works best on defragmented drives. Fragmentation causes problems - not only for Photorec but for commercial software using the same principle.

If your accounting files are using their own particular file format you could contact the author of this forum by providing at least three different samples per file type. Maybe he might decide to integrate your file format(s) into Photorec by building one or more indivual fingerprints. Depending on the extent of work you might be required to hire him as a consultant.
As your disk problems seem to be on a logical level only he might be a better contact than a professional recovery lab. Their advantage is with hardware errors.

Keep in mind that when operating in fingerprint mode even haven specific fingerprints does not protect you against recovering broken accounting files - this is a permanent risk.

Now I got an idea what happened!

CoWoAdmin wrote: 05 Sep 2020, 11:50 6.) Apparently HPE Microserver Gen10 sets up efi boot files by default on the HDD in bay 1. So, now when using Testdisk on the cloned drives I get FAT12, btrfs, Ext4, filesystems back (quick search), but I am not able to see the tree, folders or files. When going for deeper search just a few and most say when browsing 'filesystem damaged' (can share screenshots at request) - As a matter of fact the quick search doesn't return anything. The deeper search takes up more than 6 hours and returns some, but not what I am looking for.

If looking into each file system proposed after running deep search using the "p"-key (list files function) does not recover what you are looking for use Photorec or some commercial software. As your accounting files are concerned you might consider using a professional lab which might have experience with recovering your particular file type.

7.) What confuses me a lot is that Photorec recovers a lot of the files (if not all) lost without (metadata, like name, date created or modified, etc...). The issue is that I can't be sure the files are complete and not stub, and the process would apparently take up to 50 days????

Do not run brute force mode in Photorec on your big drives. The loss of metadata and recovering broken files is caused by the way Photorec works. Photorec is the last line of defense against data loss. It works best on defragmented drives. Fragmentation causes problems - not only for Photorec but for commercial software using the same principle.

If your accounting files are using their own particular file format you could contact the author of this forum by providing at least three different samples per file type. Maybe he might decide to integrate your file format(s) into Photorec by building one or more indivual fingerprints. Depending on the extent of work you might be required to hire him as a consultant.
As your disk problems seem to be on a logical level only he might be a better contact than a professional recovery lab. Their advantage is with hardware errors.

Keep in mind that when operating in fingerprint mode even haven specific fingerprints does not protect you against recovering broken accounting files - this is a permanent risk.

Big Thanks to you recuperation! The time you took to answer is greatly appreciated.

Just a few clarification. I expressed myself poorly. Our accounting files are simple libreoffice spreadsheet ones (ods file extension), but I can't seem to find the in the extensions list offered by photorec for filtering down the search results. Am I wrong? Do I need to pick the '*.doc' option for MS Office file repositories?

Anyway. Big thank you und schöne Grüsse von einem geburtigen Hamburger.

The ods-files are technically zip-files. Please select the zip file format.

Schöne Grüße zurück an den gebürtigen Hamburger von einem gebürtigen Niederrheiner.

Besten Dank.

Ich habe mittlerweile auch die SystemRescueCd auf eine Live USB gespielt. Versuche weiter...

I will select ZIP files then.

Thank you.

UPDATE - I have been lucky to talk the guy who sold me the MINEBOX (HPE Proliant microserver Gen10 - RockstorOS on USB flash stick - 2x 4TB seagate ironwolf drives for data storage under btrfs.
I read today (https://btrfs.wiki.kernel.org/index.php) that btrfs is ext4 compatible. That explains why I was able to use the 2 big HDD on the fly with the new ubuntu setup 2 years ago.
If I only could undo the RAID1 setup and partition the original btrfs to get back my files.... too stupid!

Will keep you posted with any progress I make.

CoWoAdmin wrote: 10 Sep 2020, 16:54 I read today (https://btrfs.wiki.kernel.org/index.php) that btrfs is ext4 compatible.

I think that's a little bit different. BTRFS can somehow embedd an existing ext4 partition, but if you start with an BTRFS that should never turn into ext4 - if I read that correctly.