Zero byte files after restoring file system snapshot

[spa]

Hi,
I have an F4-423 with 4 HDDs (2TB each - TRAID), 2 nvmes (512GB each - RAID 1) and 32GB of RAM.
I was trying to recover some files that I accidentally deleted permanently and I decided to restore a snapshot of the file system.
The Volume I was trying to restore was full with only 64KB free.

It took about 5/6 days to restore everything and, once finished, essentially every file in every folder had a sizing of 0 bytes and their dates are now the ones when they have been supposedly recovered.

The volume is still full.

disk-still-full.jpg

(12.13 KiB) Downloaded 168 times

I have plenty of snapshots (I locked some of them as well to be sure...)

I had a look at this as well viewtopic.php?f=25&t=5096, but my RAID status isn't corrupted and disks are good.

If anyone can help or has any suggestion, I would appreciate immensely. That's a lot of very important data there that (for some reasons) I found out it hasn't been fully backed up yet by the USB copy tasks, but that's another day's problem.

[spa]

Forgot to add TOS details if needed.
It's on version 5.1.103

os.jpg

(3.07 KiB) Downloaded 133 times

[TMRyan]

You can try editing and deleting files on volume 2 to check if the file system has become read-only due to lack of space.
When the file system does not have enough free space for write operations, the file system switches to read-only mode to prevent further writes from causing data loss or corruption.
If the file system becomes read-only, you need to repair the file system and then restore it.
How to repair file system: viewtopic.php?f=79&t=2575
What are the restore results displayed in the restore list? If the file system is normal, you can contact our technical support team to check.

[spa]

I tried to modify a 0B file and it doesn't store anything, which should enforce your theory of the read-only OS.

I followed the link provided.
The info prompted by dmesg doesn't show any corruption of btrfs

Code: Select all

[   59.454625] BTRFS: device label TOS_VOL_******** devid 1 transid 1086645 /dev/mapper/vg0-lv0 scanned by mount (2595)
[   59.454852] BTRFS info (device dm-0): flagging fs with big metadata feature
[   59.454860] BTRFS info (device dm-0): using free space tree
[   59.454862] BTRFS info (device dm-0): has skinny extents
[   59.462499] BTRFS info (device dm-0): enabling ssd optimizations
[   63.656706] BTRFS: device label TOS_VOL_******** devid 1 transid 1955548 /dev/mapper/vg1-lv1 scanned by mount (3016)
[   63.657099] BTRFS info (device dm-1): flagging fs with big metadata feature
[   63.657106] BTRFS info (device dm-1): using free space tree
[   63.657109] BTRFS info (device dm-1): has skinny extents

I will check the repairing instructions, but I would like to understand first what they actually do (losing data is clearly not the main goal here...)

To close, I'm not sure I understand your last question, though.
Can you please help me finding the info you need?

[spa]

An update for anyone who may face the same issue.

I wasn't able to restore previous snapshots, nor I was able to hot swap the disks with some new disks with more capacity.
Apparently some disks got corrupted (I guess after I tried to hot swap the first one as the one I swapped is the only one not corrupted now) and after a couple of sessions with TerraMaster engineers, they highlighted those problems with the disks themselves and addressing that as the root cause of the inability for the TRAID to rebuild (definitely fair).

Before abandoning any hope of losing the latest data, I gave a go to a different approach that worked for me, so I don't know if it's legit or risky. or not recommended...
I just wanted my files back and given they were "already lost" I gave this a go .

First of all, I was sure about the dates of the events.
As stated before, recovering a snapshot, despite succeeding, wasn't enough as the snapshot itself was carrying the full capacity problem.
My NAS has 2 volumes:
- Volume1 500GB with ~400GB free (RAID 1 on 2 nvmes)
- Volume2 5.3TB with 64KB free (TRAID on 4 HHDs) <== the problematic part
I roughly knew the overall folder structure and what I was after at the point in time I was referring to.
I operate through a Windows machine.

1. I created a temporary shared folder in /Volume1 that was easily accessible both through ssh and Windows
2. I did ssh into the NAS
3. I dug into /Volume2/@sysSnapShoot/BTRFS_snapshot/... to find my snapshot
4. I dug even more into the snapshot subfolders to find the locations I needed
5. I verified that the files in the snapshot weren't 0B
6. copied one for test, then all of them from the specific subfolder to my temporary folder in /Volume1 (something along the lines of `cp *.jpg /Volume1/public/recovery`)
7. pulled the files from windows onto external backups
8. repeated for the files/folders I needed

I know it's not ideal, it's a lot of time and I cannot guarantee in any way that this approach would consistently succeed, but it allowed me to safely recover all the files that I was missing from my backups.

Now I'm in the position of being able to simply delete anything that's on the HDDs or take the array out, insert a brand new one and go from there.

I hope this may be of any help if anyone encounters the same problem and you are one step far from simply formatting and start over.