Beiträge von jollyrogr

Zitat von olduser

DIRTY(Create a share named "bay_3_$UUID" to identify a physical disk). You should probably use stickers with the UUID on it. Of course, a user editable label/name is nice for those without proper backplane modules.

Tags work for me, and I can also use the ledmon tool to flash the LED on /dev/sdX so I can identify which bay the drive is in. My server has 24 bays so I need to have a method to stay organized. Using share names as you've suggested would break mergerfs, so that is not an option for me.

You should not include the OS drive in a snapraid array. I would also not use OS drive for data storage.

UUID eliminates issues with the system identifying drives - it's just not human friendly. I now use tags to identify the slot drives are in instead of labels.

You should run it in a VM. It's not possible to hardware passthrough on a CT. You could potentially mount the drives on the host and then share the mounts with the CT, but I don't see any reason to use OMV at that point. You might as well use proxmox as the NAS.

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.

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

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.

I use wireguard. This way my phone is always on my home network so that I can use my pihole DNS 100% of the time and eliminate snooping by my phone provider.

And in the event that I need to administer something on my home network while away from home, I can SSH to any box in a few seconds.

I have also not had an issue installing OMV on proxmox 7 or 8. VM config looks very much the same, only like Krisbee, I use "host" for processor.

Edit: I get that there are advantages to not using "host" - makes it easier to move VM's to new hardware. But if you want to virtualize the CPU, just use kvm64.

At this point I'd probably wait until 7 is final and then do a fresh install of that.

You could insert a new drive and recreate parity on it. My preference would be to copy the parity to the new drive and then replace the drive in the array. Either way should work but I think copying parity would be faster and result in less wear and tear on the drives.

Agree with the others, definitely stay behind a firewall and use Wireguard. A non-standard port does nothing for security - only slows a hacker down by a few seconds.

Zitat von Krisbee

This thread has long strayed from it’s original topic and risks descending (further?) into the level of a school playground with some gratuitous foul language thrown in. I will say just one more thing about this.

Let’s start with a definition of redundancy that we might agree on:

A way of storing the same data in different places on multiple hard disks or solid-state drives (SSDs) to protect data in the case of a drive failure

Elsewhere you advocate that “Snapraid and mergerfs is still the best in my opinion”. A system that obviously offers a form of redundancy. Yet now you appear to recant, or least say what’s good for you, other home users don’t need. An attitude that’s hardly going to garner support.

Alles anzeigen

It appears you did not understand what has been said. Snapraid is not a filesystem. I use it on top of ext4 filesystem and it works very well. I absolutely recommend for home users.

Zitat von chente

What if a home user wants/needs a file system with redundancy? What would be your recommendation?

You said home user, so my opinion is no, they don't need it.

Zitat von chente

And what would you recommend to home users?

EXT4

Zitat von Krisbee

jollyrogr We can go round in circles about zfs & ECC all night if you want to but it's an old cannard and a waste of time. Latest OpenZFS statment is here:

https://openzfs.github.io/open…to-use-ecc-memory-for-zfs

Haha whatever. IMO ZFS itself is a waste of time. Running enterprise file system on shit hardware - play stupid games, win stupid prizes. Reminds me of the people running a NAS on a raspberry pi with USB drives in a raid5 looking for help when the array fails. That statement should be revised to say "for home users, ZFS is not needed nor recommended". But they would never say that because that would eliminate the bulk of their user base.

Zitat von Krisbee

It wasn't really a serious question, but I wonder what would happen if your had this sort of failure mid sync?

SnapRAID

What happen if a disk breaks during a "sync" ?

You are still able to recover data. In the worst case, you will be able to recover as much data as if the disk would have broken before the "sync". But if the "sync" process already run for some time, SnapRAID is able to use the partially synced data to recover more. To improve the recovering you can also use the "autosave" configuration option to save the intermediate content file during the sync process.

So I interpret that as you can recover 100% of synced data and as much as had been synced during the sync process until the disk failure. This is why I copy files to the array then sync before removing the original from desktop/laptop.

Zitat von chente

Whether or not you need ECC memory is not unique to ZFS. It can be applied to any file system. The only difference is that the ZFS documentation placed more emphasis on this aspect and the others did not.

Agree with the first two sentences. 3rd one not so much.

Quote from Joshua Paetzel, one of the FreeNAS developers:

Zitat

ZFS does something no other filesystem you’ll have available to you does: it checksums your data, and it checksums the metadata used by ZFS, and it checksums the checksums. If your data is corrupted in memory before it is written, ZFS will happily write (and checksum) the corrupted data. Additionally, ZFS has no pre-mount consistency checker or tool that can repair filesystem damage. [...] If a non-ECC memory module goes haywire, it can cause irreparable damage to your ZFS pool that can cause complete loss of the storage.

Zitat von Krisbee

So what happens if your parity drive dies along with a data drive? Just kidding, but I've always looked at this as horses for courses. Did anyone ever try to chart the pros and cons of the various methods of handling multiple drives in OMV alongside criteria for deciding best choice?

I recover both. I have two parity drives and 8 data drives at the moment so I can recover from a failure of any two. As my array expands I'll probably look to add a 3rd parity drive.

OMV on Proxmox should still work. I think the ZFS was limiting. Shouldn't be using it without ECC memory anyway.

Snapraid and mergerfs is still the best in my opinion. If something else did become available, I would be skeptical of it until some track record of success had been established. Snapraid is mature and proven. Off hand I can't think of any feature that's missing.