Why not change your command line commands to use -c and the path to the new config file?
Yep, I'm doing that once I became aware of the situation. I'll probably just mv snapraid.conf snapraid.conf.deprecated or something like that to prevent accidental usage. Just wanted to make you aware of the potential for folks to use the wrong snapraid conf after upgrading. (only nerds like me that use terminal a lot though)
There is nothing in the code that removes it.
OK. I guess it would only be an issue if people run snapraid from the terminal like me. People running it from the web interface should have no issue. And for me it's not an issue until I would make a change to the array.
The plugin being upgraded to v7 upgrades the database and runs the saltstack code. So, the config file in /etc/snapraid/ should already exist.
I would delete /etc/snapraid.conf because it won't be maintained anymore. But I don't know what you do outside the plugin to know if something else will break.
Yep the .conf files exist in /etc/snapraid/
Just letting you know that /etc/snapraid.conf was not removed and I don't know if the upgrade was supposed to do that. I think i'll remove it and start using "-c array1.conf" in my commands.
I just added code that will create a symlink to each array's config file using the array's name. I tested using the symlink from the command line and it works as expected.
I just migrated my omv 6 systems to 7. I noticed that after migrating /etc/snapraid.conf still exists and snapraid commands work the same as before. I assume this is because I haven't made any configuration changes to the array? If I do, the plugin will update /etc/snapraid/array1.conf, correct? Maybe I should delete /etc/snapraid.conf...
Alles anzeigenI 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!
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.
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.
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.
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.
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.
Alles anzeigenThere 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.
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)
