JonathanM

That's exactly what pools are, and have been for the last few years.

Backup implies that you can get data back if the primary copy is corrupted or deleted. 2 drives in a mirror is not a backup, it only protects from a drive failure. Yes, you could set up a real backup to make periodic copies to the array, or even better, a destination not in the same box.

Array will be online and usable while parity builds, but access will be slower, and also extend the build time. Are all the drives you want to remove empty? SSD's in the parity array isn't recommended, it will work, but it will be slower than if you used it in a pool. Trim can't be enabled on array drives so SSD read speed may decline over time.

Containers have data on your drives, so at least some of them must make the trip. It would be easier to move all the current drives along with the USB to a new machine, then upgrade the drives you want to replace.

Yes, but it would be easier to continue to use the same physical USB stick on the new server, that way you don't need to migrate the license. All your customization lives in the config folder, so just make a copy of that minus the trial.key file, erase the config folder on the old USB, making a backup first just in case, copy your new config folder to the old USB, put the license file that belongs to the old key back in the config folder, and you're done.

Yes, format (or file deletion) simply amends the table of contents to show the space is available for new files or directories. The raw bits that are files are still there, and file recovery software can make an attempt to sort through the mess and see if it can find anything sensible. To extend the analogy, formatting a drive dumps the contents of the folders on the floor. All the papers are still there, but good luck picking through them to find any specific one, let alone figuring out if you have all the papers that belong to any given file. There would be clues, like all movie files start with the name of the file and encoding type, but all the rest of the pages would look like random garbage.

http://forums.unraid.net/index.php?topic=36543.0 Factory reset plugin

You can just manually copy the backup to the flash, no need to use the restore function. The config folder should be all you need.

Not well. That's one of the main reasons RAID controllers are strongly not recommended. If the RAID card doesn't mess with drive geometry (some do) then the only thing needed would be to correctly identify the drives and match them to their slots. If the RAID card alters drive geometry then it's quite possible you will end up with incompatible partitions, which may or may not be fixable without data loss. Always use plain HBA cards, or make sure the RAID controller is in IT (not IR) mode. Simply assigning each drive on a RAID card to a RAID0 may allow the card to work, but you are still going to possibly have all the above issues. Some RAID cards don't have IT firmware. Also, some cards don't pass critical SMART data correctly, meaning Unraid will not be able to help you stay on top of drive health issues. As always, make sure you have any critical files backed up. Unraid or any RAID is NOT backup, it's high availability. You must still keep a second (or more) copies elsewhere. Worst case you may need to restore from backups if the migration isn't successful.

Do you have a flash backup?

See if this applies.

Remove all the partitions and see if that helps.

Take a look at the ident.cfg file in the config folder.

Nope. Those only increment upwards, the only way to reset them is with double top secret expensive stuff that theoretically only manufacturers can get. It's kind of like an odometer in a car, only I'm not aware of any laws specifically keeping them from being reset.

SATA connections are crappy designs. The don't positively lock, and have poor contact patches that are prone to oxidation over time. More expensive cables, read ones that actually meet the written specs instead of engineered to a bottom price, can help somewhat, but every once in a while you just need to pull and reseat the cables to ensure good clean metal on metal contact for all the many pins.

Because theoretically it means out of the box ANY single network connection will make the GUI available over the net, without additional configuration. Most server grade motherboards include multiple NICs, so instead of forcing people to either connect locally and configure eth0, or play "pick a port" to figure out which physical port got assigned eth0 by default, any single network connection should just work out of the box. I agree it can cause issues if those assumptions (single network cable to switch) aren't true. If I'm way off base feel free to correct me.

This needs to be clarified. It will NOT clear the drive, parity must still be resynced after the drive is removed. It will empty the drive of files, but that is very different than clearing the drive.

Try deleting all the ._ files, perhaps they are causing an issue? @Squid, am I missing something obvious?

Check your krusader recycle bin settings.

What is the content of that folder?

You formatted the emulated disk1, not the physical disk.

look in the previous apps section of the apps tab

How will unraid know the difference between a drive failure and the much more common communication failure? Both result in a write failing, which drops the drive, but communication failures often effect more than one drive, and trying to rebuild without correcting the issue could cause the rebuild to be corrupt. Automatically starting a rebuild without investigating the cause is risky, at least with your current method you can look at the syslog and smart reports and see if it's a clean drive failure, as well as monitoring the rebuild process. I get it, you want the option to add risk to gain convenience, but that's not normally the path taken with adding unraid features. You have to balance the time spent on developing and testing a feature against the amount of gain by adding it. Development time is a hot commodity, and since ZFS already supports hot spares it's going to be a hard sell to modify the traditional unraid array.

The issue with this is the vast majority of dropped drives aren't actually bad, the issue lies with the controller, power, or interface cables. Automatically doing anything without assessing why the failure happened risks making a recovery into a data loss situation. Better to alert the operator to allow intelligent assessment and proper mitigation before causing harm.

Where did you see that?