Snapraid data disk failure

DO NOT run a sync until you have repaired the array and data is restored. You will need a drive to replace the failed one. crashtest correct me if I'm wrong, but it wouldn't need to be 16TB, just large enough to hold the data that was there previously?

I would buy another drive to fix your array and then RMA the bad one. When you get the replacement drive, keep as a spare for the next time you have a failure.

Another thing to keep in mind is that SnapRAID does not restore ownership, permissions, and extended attributes. The files that are restored will be owned by the user that ran the fix command, typically root, and the permissions will be set mode 0600.

Zitat von crashtest

I've never tested it but I believe you're right. SnapRAID restores files only. It doesn't do an "image" based restoration. So a drive larger than 2TB, with a good sized pad, should be sufficient. (I'd go with a 3 to 4TB just to be sure.)

Snapraid's online manual seems to indicate that you just need enough space to recover.

Zitat

4.4 Recovering

The worst happened, and you lost one or more disks!

DO NOT PANIC! You will be able to recover them!

The first thing you have to do is to avoid further changes at your disk array. Disable any remote connection to it, any scheduled process, including any scheduled SnapRAID nightly sync or scrub.

Then proceed with the following steps.

4.4.1 STEP 1 -> Reconfigure

You need some space to recover, even better if you already have additional spare disks, but in case, also an external USB or remote disk is enough.

Change the SnapRAID configuration file to make the "data" or "parity" option of the failed disk to point to the place where you have enough empty space to recover the files.

For example, if you have that disk "d1" failed, you can change from:

Code data d1 /mnt/disk1/

to:

Code data d1 /mnt/new_spare_disk/

If the disk to recover is a parity disk, change the appropriate "parity" option. If you have more broken disks, change all their configuration options.

4.4.2 STEP 2 -> Fix

Run the fix command, storing the log in an external file with:

Code snapraid -d NAME -l fix.log fix

Where NAME is the name of the disk, like "d1" as in our previous example. In case the disk to recover is a parity disk, use the "parity", "2-parity" names. If you have more broken disks, use multiple -d options to specify all of them.

This command will take a long time.

Take care that you need also few gigabytes free to store the fix.log file. Run it from a disk with some free space.

Now you have recovered all the recoverable. If some file is partially or totally unrecoverable, it will be renamed adding the ".unrecoverable" extension.

You can get a detailed list of all the unrecoverable blocks in the fix.log file checking all the lines starting with "unrecoverable:"

If you are not satisfied of the recovering, you can retry it as many time you wish.

For example, if you have removed files from the array after the last "sync", this may result in some other files not recovered. In this case, you can retry the "fix" using the -i, --import option, specifying where these files are now, to include them again in the recovering process.

If you are satisfied of the recovering, you can now proceed further, but take care that after syncing you cannot retry the "fix" command anymore!

4.4.3 STEP 3 -> Check

As paranoid check, you can now run a "check" command to ensure that everything is OK on the recovered disk.

Code snapraid -d NAME -a check

Where NAME is the name of the disk, like "d1" as in our previous example.

The options -d and -a tell SnapRAID to check only the specified disk, and ignore all the parity data.

This command will take a long time, but if you are not paranoid, you can skip it.

4.4.4 STEP 4 -> Sync

Run the "sync" command to re-synchronize the array with the new disk.

Code snapraid sync

If everything is recovered, this command is immediate.

Alles anzeigen

Zitat von gderf

Another thing to keep in mind is that SnapRAID does not restore ownership, permissions, and extended attributes. The files that are restored will be owned by the user that ran the fix command, typically root, and the permissions will be set mode 0600.

Good point. I think this can be easily fixed using the resetperms plugin.