[ Resolved ] USB flash drive failed and corrupted

[icopy]

What happenned:

* Log filled with ECC Error.  Syslog is filled with memory error logs. See attached diagnostics files. Usually solvable by rebooting.

* Fail to reboot. I tried to reboot the system, but console showed "SYSLINUX: No DEFAULT or UI configuration directive found!"

* USB Flash data corrupted. I found syslinux configuation file is corrupted. Later, I discovered that most of the files on the flash drive has been corrupted.

 

What I am trying to do:

* Preserve array data. I have a 8 disk array with 2 parity drive. I am not sure what to do to safely transfer new config on to a new flash drive.

* Preserve VM data and config. 

* Preserve plugin / docker data and config.

  - Jellyfin. I've installed Jellyfin as media center. Although it does not has significant data value but I've spent quite a lot time on it. Is it possible to preserve its data and configurations. 

  - Other plugin to help run Unraid and UPS, such as CA, Nerd Pack, NUT.

 

How should I proceed? 

* I bought a new flash drive and read wiki https://wiki.unraid.net/UnRAID_6/Changing_The_Flash_Device.

* I'm looking for better way to preserve data and config.

 

Thanks.

 

 

 

 

tower-diagnostics-20201216-2224.zip

Edited December 30, 2020 by icopy

[itimpi]

Can you read anything of the old flash drive?   Everything that is specific to your system is stored in the 'config' folder on the flash drive.

 

If not, then do you have a copy of your licence file?  This will be needed to transfer the licence to a new flash drive.  If not then need to contact Limetech by email to resolve this.

 

The chances are that all you data is intact although one cannot be sure after RAM errors.  Do you know which driver were parity drives and/or cache drives?  If not then we can walk you through the steps that should help work this out.  However if you cannot get the contents of the 'config' folder then at the very least you are going to have to reconfigure any docker containers or VMs.

 

A bit late now, but it is worth pointing out that you can always make a downloadable backup of the flash drive by clicking on it on the Main tab and selecting the backup option.  Always a good idea any time you make a significant change just to cater for scenarios like you currently have.  The CA Backup plugin can also be used to automate taking backups of the flash drive and docker container files.

[icopy]

1. Can you read anything of the old flash drive?   Everything that is specific to your system is stored in the 'config' folder on the flash drive.

I've managed to copy some of the config files from the flash drive. Most of the text files seem to be intact. But I can't say the same for other binary files. Is Plus.key the license file? It seems to be encrypted.

 

2. Do you know which driver were parity drives and/or cache drives?

The smart info in diagnose files and my last config log are inconsistant. I don't know which one is correct.

sdb-sdi are consistant. The disk numbers are not.

The smart info is much more recent. My config log is at least 6 month old.

Config log:

 

Smart info:

Samsung_SSD_970_EVO_500GB_S466NX0MC14637H-20201216-2224 cache (nvme0).txt
ST4000VX007-2DT166_ZGY6NXYW-20201216-2224 disk5 (sdh).txt
ST4000VX007-2DT166_ZGY6P1S4-20201216-2224 disk6 (sdi).txt
ST4000VX007-2DT166_ZGY6P66Q-20201216-2224 parity2 (sdg).txt
TOSHIBA_MD04ABA400V_2869KY7EFMYB-20201216-2224 disk4 (sdf).txt
TOSHIBA_MD04ABA400V_58BXKCXIFMYB-20201216-2224 parity (sdb).txt
TOSHIBA_MD04ABA400V_58D1KAVXFMYB-20201216-2224 disk3 (sde).txt
TOSHIBA_MD04ABA400V_58DFKVTFFMYB-20201216-2224 disk2 (sdd).txt
TOSHIBA_MD04ABA400V_58EOKCF9FMYB-20201216-2224 disk1 (sdc).txt
VendorCo_ProductCode_920702127A907718462-0-0-20201216-2224 flash (sda).txt

 

The latest parity check is on Dec 7th. The ECC error began as early as Aug. 

2020 Sep  7 18:58:50|66529|60.1 MB/s|0|0
2020 Dec  7 18:13:16|63795|62.7 MB/s|0|0
 

[itimpi]

The plus.key file will be your licence file.    It is encrypted so not human readable.    The super.dat file is also not human readable.     The rest of the configuration files will be text files.

 

The important thing in setting up the disk assignments is to not accidentally assign a data drive as a parity drive as that will destroy its contents.  
 

One thing you can do is use the Tools=>New Config option and then assign ALL disks you are not sure of as data drives.    When you start the array the parity drives will be unmountable as the parity drives have no file system and the data drives should mount with their contents intact.   An alternative approach is to try mounting them using the Unassigned Devices plugin and again the parity drives will fail to mount.    Whichever way you go make sure you note down the serial numbers for the next steps.  Hopefully you will not have more drives failing to mount than you have parity drives, but if so report back and we might be able to give some advice.   This will not tell you which is disk1, disk2 etc but you might be able to tell by the disk contents.

 

if you now do Tools => New Config you can assign the correct parity drives and data drives.    When the array is started the system will start to build parity based on the data drives, and the content of the data drives will be left intact.

 

if you have anything set up to go to specific drives you will now need to make sure that this matches your current assignments.

 

[icopy]

Here's what I should do. Please see if I get it right.
1. Build a new flash drive. 

2. Copy all the config files onto the new flash drive.

3. Start the machine and use webUI to transfer keys.

4. Use Unassigned Devices plugin to verify disk to be data or parity.

5. Reconfig the array. 

 

I should get:

1. Data on array intact.

2. VM, Docker and other settings intact?

 

By the way, does the order of disk (disk1, disk2, ....) matter?

 

Thanks.

 

 

[trurl]

config/super.dat has your disk assignments and it looks like your backup of that file is OK so you shouldn't have to reassign anything. Just in case, edit config/disk.cfg and change it so it doesn't autostart and you will be able to check the assignments before starting.

[icopy]

15 hours ago, trurl said:

config/super.dat has your disk assignments and it looks like your backup of that file is OK so you shouldn't have to reassign anything. Just in case, edit config/disk.cfg and change it so it doesn't autostart and you will be able to check the assignments before starting.

Great News.  Do you mean:

Changing: <<<===========

# Generated settings:
startArray="yes"

To: ==========>>>>

# Generated settings:
startArray="no"

 

Thanks.