Beiträge von jollyrogr

Zitat von auanasgheps

I would recommend taking a look at borg as a proper backup solution. It is super, super reliable. It has versioning, encryption, compression, deduplication.

It takes care of my off-site backups to a NAS at my parent's house. Whatever happens on my local SnapRAID array I have a weekly backup, along with a history/versioning of the last 3 months.

It virtually runs on anything: for this I'm using a 10 years old Synology NAS and a shucked drive I paid very little for.

The cost is small, you can automate it using borgmatic and then you'll sleep well!

Alles anzeigen

That does look neat. Offsite backup is ideal but I would neat a bit more upload speed. And I would need to build another 30tb NAS.

Zitat von ryecoaaron

While I was reminding you of that, that message was really for other people reading this. You are free to do whatever you want. I think it is strange that you are willing to risk backup on something that provides availability and redundancy but are worried about losing one file. But if it works for you, so be it.

Not sure I get what you mean there. I like snapraid because it provides redundancy (snapraid is really not for availability IMO) and data protection without having to invest in more drives for a 1 to 1 backup. As my drives age and as larger drives become cheaper, I could start to look into adding a second array for backing up the first.

My first server only had 8 bays and my current one has 24, so I do have room to expand a bit.

Zitat von ryecoaaron

Sounds like you are using snapraid as backup and snapraid isn't backup (just like raid).

Yeah that's pretty much what I am doing and it has worked well for the last 6 years or however long I've been running this (since omv2). So there is a level of risk I have accepted and I'm not going to increase it by automating the sync.

Zitat von auanasgheps

Have you tried my script? Has many logics to prevent unwanted syncs.

Nice update to the original script, and correct me if I'm wrong, but it still just uses a threshold value to determine if a sync will be performed. If a single file is corrupted due to a bad sector on a disk and your threshold is >1, then it will sync and wipe out any possibility of recovering that file. I'm not interested in that. It isn't that difficult to manually sync my array when adding/removing files.

Zitat von ryecoaaron

Seems like the plugin (I assume that is what you mean by automation) could be enhanced if people provided suggestions.

The plugin is fine. By automation I was referring to the diff script. I'm not sure there's any enhancement that would make me trust it. If there are changes to the array, I want to know what they are before syncing.

Zitat von crashtest

There are a number of variables. Sync, for new, changed and deleted files, tends to be pretty fast. On the other hand, the size of the data store, speed of the drives, USB connected drives, etc., effect the length of time required for a scrub. To avoid issues (errors) with a sync and the following scrub, it's best to run and automated Diff after-hours when the server is not being used. After-hours, where user access is unlikely, may mean something between midnight to 06:00AM. If the data store is large, requiring several hours to complete a scrub, scrubbing less than 100% of the store may be necessary.

With the above in mind, I'm of the opinion that scrubbing 25% of the store, once a week, is enough. In a month's time, all is checked for data integrity. Along with keeping an eye on SMART data, I believe that's enough.

What I keep an eye on are differences thresholds, when setting up Diff. (Changed, new and deleted files.) While a reasonable number of changes must be allowed or the script won't complete (negating automation), excess changes are an indication that a closer look is needed. For automation purposes, I've found that 100 each, per week is enough. Otherwise, if I add lots of files or do a large delete, I run a sync manually.

In the bottom line, it's best to read up on what SnapRAID does, try to get a good understanding of how it works, then set it up according to what works best for you.

Alles anzeigen

I don't trust the automation either. I run a diff and sync manually after adding/removing files on the server. I manually run scrubs periodically, not as often as I probably should.

IMO OMV is a Debian based NAS and does an excellent job reliably serving my network. All the necessary plugins are there. I don't use Docker for anything because there aren't any core functions that need it.

I run NAS or enterprise drives and never spin down. They run 24/7/365. Personally I think spinning down and up is harder on drives and leads to more failures.

To be blunt, seems like all the items are readily implemented by anyone that's not a noob or is willing to put a small amount of effort into learning. OMV is pretty turnkey as it is.

I use the plugin for configuring the array. Daily tasks like diff, sync, scrub, status I find easier to do via ssh terminal.

I use the command line exclusively for managing snapraid. To make things easier, can I link the conf to a more friendly filename?

Do you have to use the -c /path/to/conf for all commands? Like diff, sync, scrub? Otherwise snapraid wouldn't know which array it's working with, right?

I've only had one SSD ever have bad smart values and that was a cheap hynix. The drive never actually failed but I swapped it out with a samsung SSD that I had on hand as a precaution.

I would exchange it. Too much $ for a 4 TB drive to have to put up with bad smart values out of the box.

Is it bad to do updates via ssh? I find it easier to use omv-upgrade command in ssh terminal.

Has to be a bios setting that is messing with you. Odd that it worked before. Are you using the same boot method as before? (GRUB vs EFI)

Another potential option is to try installing debian and if that boots then install OMV on top.

That's one hell of a system. I can't speak to unraid because I've never used it. Because I've never needed to.

Zitat von olduser

It's almost certainly the backplane unless your HBA is stripping packets/headers, which would be crazy. I tried requesting a couple samples from AMI of the MG9094 (still "solderable") but unsurprisingly never heard back. I couldn't even find a proper datasheet for _ANY_ of the controllers no matter manufacturer or age.

AMI backplane controller matrix (PDF)

Makes sense because the case is a Norco that I'm not even sure is made anymore and the backplane is made by God knows who. It was what I had before I got the supermicro 846. I'd like to retire the Norco and get another supermicro (826 or 836) for a backup server. It's actually been trouble free for the 7 years it's been in service but I would like to move to a rackmount enclosure since I have a rack now.

Zitat von olduser

Sure, but the association of which physical drive is on /dev/sdX is not guaranteed, not even with a backplane module. Of course you could mean that you're simply flashing the light on which ever driver is broken/focused, which obviously works and is good enough. But if you don't have a proper backplane module, how do you do that? You can't.

Correct, so you need to verify sdX nomenclature first. All you need to do is identify the drive in the OMV web UI by UUID and /dev/sdX and then open a terminal and use ledctl command to flash the LED. Though it certainly does not work on all machines. It works great on my 24 bay supermicro but not on the other 8 bay no-name machine. I'm not sure if it's the HBA or the backplane that is the problem...