[SOLVED] URGENT HELP Please: Deleted files from the flash by mistake, how do I restore it?

[abhi.ko]

So I did execute

rm -rf \*

on accident and then stopped it pretty quickly (<2s), and the command generated a bunch of cannot remove messages,

 

now the Web UI doesn't work, but the shares, docker containers all seem to be live and working.

 

I do have my appdata and USB backup folder but the USB Backup permissions doesn't seem to be correct and I can't run chmod or almost any command from the terminal - it says command not found.  

 

How do I fix this without having to reconfigure everything again?

 

Edited September 24, 2020 by abhi.ko

[Squid]

What you need to do is this (assuming the USB backup is on the array)

 

• Set up a new flash drive as a trial
• Assign ALL drives as DATA drives.
• Start the array.  One or more will come up as unmountable.  Do NOT format them.

You should now have access to the Flash Backup share.  Copy it to your old flash drive.

 

Reboot with the old flash drive.  Everything *should* be good.

[abhi.ko]

3 minutes ago, Squid said:

What you need to do is this (assuming the USB backup is on the array)

 

• Set up a new flash drive as a trial
• Assign ALL drives as DATA drives.
• Start the array.  One or more will come up as unmountable.  Do NOT format them.

You should now have access to the Flash Backup share.  Copy it to your old flash drive.

 

Reboot with the old flash drive.  Everything *should* be good.

Yes the USB backup is on the array, under a share.

 

So please bear with me:

What do you mean by - Assign ALL drives as DATA drives.

I have never checked the USB Backup location before this, just trusted the Appdata Backup plugin to do its work, is there any way to check the contents in that drive, ls command doesn't work. Just wondering if the backup is not there, then what?

I haven't yet powered the system down, because I am afraid I will loose access to shares and dockers and their configs, db's. So anything I need to do before shutting the system down. Download or move stuff? 

 

[Squid]

Yeah, you've trashed the in RAM OS, along with the boot flash drive.  In order to gain access to the shares and your flash backup, you need to set up another flash drive as a trial.

 

Since (presumably) you don't know what drives are what, you assign them all as data drives.  It's harmless so long as you don't click "Format".  Then you've got access to the shares and can restore your backup of the flash.

3 minutes ago, abhi.ko said:

So anything I need to do before shutting the system down.

Nope.  Any damage done is damage done at this point.  Assuming you stopped the command before it hit /mnt, then all of your data is safe

[abhi.ko]

Thanks @Squid, appreciate the help and patience.

 

I found a back up from June (06/24) saved on my desktop - I think I replaced the USB drive then and this was saved for that.

So can I use anything from this?

 

The config folder and disk assignments should be pretty accurate.

[Squid]

9 hours ago, abhi.ko said:

disk assignments should be pretty accurate

Pretty accurate and is accurate are two different things.  If there's any doubt if you moved the parity drive to be a data drive since June, then delete super.dat and reassign the disks manually.

 

Other than that, everything in /config you want.

[abhi.ko]

Thanks Squid.

I did grab it from the USB backup share as per the plan you suggested (that was a backup as of Monday morning) and now everything is good, parity rebuild is in progress. Not sure why parity had to be rebuilt though?

[trurl]

21 minutes ago, abhi.ko said:

Not sure why parity had to be rebuilt though?

Did you start from New Config and reassign your disks? If so, parity is rebuilt by default from New Config unless you check the box saying parity is valid.

 

OR

 

Is it actually rebuilding parity, or just checking parity? Parity check from unclean shutdown is expected when you restore a backup super.dat (disk assignments) unless the backup was taken with the array stopped.

 

In addition to disk assignments, super.dat records the array stopped / started status. If super.dat doesn't say the array was stopped when you boot, it assumes an unclean shutdown.

[abhi.ko]

23 minutes ago, trurl said:

Did you start from New Config and reassign your disks? If so, parity is rebuilt by default from New Config 

Yes, all the disk assignments came up empty after boot and I had to reassign the disks manually, the Disk Assignments.txt in the config directory that was saved a day earlier is what I used for reassigning and they are right.

 

Not sure why they had to be manually reassigned, after I copied over the contents of the flash from the 9/21 back up and made the disk bootable, I thought it would retain the disk assignments.

Quote

unless you check the box saying parity is valid.

I did not check that box, I should have, the parity was valid.  I remember seeing that box and thinking, if I don't check it, it will just do a parity check. Did not realize that it will trigger a rebuild.  It is definitely rebuilding parity, but all the shares, dockers, plugins, and data seems to be fine.

 

Is there a negative, if the parity is rebuilt? Other than the array being unprotected for the rebuild duration.

 

Edited September 23, 2020 by abhi.ko

[trurl]

9 minutes ago, abhi.ko said:

Is there a negative, if the parity is rebuilt? Other than the array being unprotected for the rebuild duration.

No. Parity rebuild could be faster than parity check since it doesn't bother to check.

 

And, if the parity is valid, it is just overwriting with the same parity data. You could recover another disk if necessary with another New Config and the invalidslot command.

[abhi.ko]

Great - thank you both. will mark this as solved now. Appreciate all the help.