Since im still working on setting up my array i cant give you any advice on the delete treshold etc. (im still playing around withit myself :))
I would definitly run the touch command, some files have pretty inacurate timestamps and the touch command just adds some more resolution to them to make it easier to detect changes.
I would say you can comfortably set the delete threshold somewhere around 200. If you delete a folder that contains a bunch of small files (simple apps, git repos, etc) - you could end up with a large change. But you generally should see something more than that if a whole disk was lost. It seems that the delete threshold is really geared toward identifying when a Sync should NOT be run because something unexpected happened - i.e. disk failure, inadvertent deletion, accidental deletion, etc.
On the timestamp piece, I haven't really noticed it to be a problem worth messing with my files to adjust this. I may change my mind, but I'm in the same boat of being slightly newer to this and haven't determined how worthwhile that will be. I need to finish of moving some things off an old Synology VM system so I can steal a disk and do some tests on restore functionality and such with SnapRAID. Not to mention get my replication setup for true backup purpose - a la Crashplan.
------------------
Separate question I'd like to pose, is an ability to set the Time that my Cron job is running daily? I've set it up as advised previously to run every day, but it seems to run at a time which is most common for new fresh NZB downloads to happen - these changes cause modifications in files, resulting in file errors during a Sync job. Any way to account for this? I'd like to specify the daily job to run around 3AM.
@ryecoaaron - I think we may have the increment by 2 issue happening again ... I just saw this AM report which said 2, and I recall the previous night the SCRUB ran. I'll wait until tomorrow just to make sure as I did have some other random runs happening as I was cleaning up an issue I had. If I can validate this again, I'm not sure what I can provide to help illustrate. I checked line 416 and it is commented out with the comment about taking it out due to the increment happening. I may have to go for a temporary solution of setting the number to 14, so I get a true 7 day run. 
There is only one active counter increment in the code. Makes me think you might have two scheduled jobs?
Makes me think you might have two scheduled jobs?
Nothing changed between when I made the comment out on the one you mentioned previously, which resulted in single increments, and when you updated the plugin.
I tried to search in crontab or cron.daily to see if I can find the job and I can't even find it. Is there somewhere else I should be looking to validate on the local system? Inside the GUI I can confirm I only have one scheduled job for the daily run of the script. I would imagine if it was setup for more than one, I should also receive more than one email report which I don't.
Anywhere else I can look to validate? Or is it possible if I was to run a manual sync this would increment the counter? - I was under the impression is shouldn't, only the script should be incrementing the timer, but just thought to make sure on this point.
Not sure where else to look. Nothing would increment it except for the script. I just think the script needs to be replaced. Can you start using the updated script without all of the OMV changes to see if it works. We could add OMV stuff to it instead of trying to fix the current one.
I think there might be something else at play. Let me see what happens tonight when it runs. I just tried manually running the Scheduled Task, and it incremented by 1. So it makes me thing there may be something else I need to identify in this, or that it could be from something I did recently that was screwing up the outputs. I'll check in the AM to see how it runs and let you know before I take any drastic steps.
I think I found an issue with the omv-snapraid-diff script.
[2017-01-24 04:30:01] omv-snapraid-diff: INFO: 'SCRUB_OLDER_THAN_DAYS not set in '/etc/snapraid-diff.conf''
[2017-01-24 04:30:01] omv-snapraid-diff: INFO: 'set it to 0'
but /etc/snapraid-diff.conf looks like this:
this file was automatically generated from
# openmediavault Stone burner 2.2.13
# and 'openmediavault-snapraid' 1.5
SYSLOG="true"
DEBUG="false"
SENDMAIL="true"
RUN_SCRUB="true"
SCRUB_FREQUENCY_IN_DAYS=7
DEL_THRESHOLD=10
SCRUB_PERCENT=100It seems the script is referencing a variable in snapraid-diff.conf that doesn't exist. I can't simply change snapraid-diff.conf since it says that it's generated by the plugin.
It seems the script is referencing a variable in snapraid-diff.conf that doesn't exist. I can't simply change snapraid-diff.conf since it says that it's generated by the plugin.
It is probably set somewhere later in the script and/or is not present in your script because you have not set this anywhere. The script should check for the presence of that variable and then use it in comparison to the SCRUB_FREQUENCY variable later in the script. If you haven't set this variable in your SnapRAID config, it's probably not populated yet and thus the message you see about setting it to 0.
It is probably set somewhere later in the script and/or is not present in your script because you have not set this anywhere. The script should check for the presence of that variable and then use it in comparison to the SCRUB_FREQUENCY variable later in the script. If you haven't set this variable in your SnapRAID config, it's probably not populated yet and thus the message you see about setting it to 0.
Where are you supposed to set the variable? There's no option in the plugin. What I'm saying is that it appears to me that the plugin setting that sets "SCRUB_FREQUENCY_IN_DAYS" should really be setting "SCRUB_OLDER_THAN_DAYS". But that's just my opinion, I could be wrong.
There's no option in the plugin. What I'm saying is that it appears to me that the plugin setting that sets "SCRUB_FREQUENCY_IN_DAYS" should really be setting "SCRUB_OLDER_THAN_DAYS". But that's just my opinion, I could be wrong.
Both parameters exist in the script. So, SCRUB_FREQUENCY_IN_DAYS is not the same as SCRUB_OLDER_THAN_DAYS. That said, SCRUB_OLDER_THAN_DAYS should probably be in the plugin as well. When I created that part of the plugin, I was following advice from a user since I am not a user of this plugin.
Both parameters exist in the script. So, SCRUB_FREQUENCY_IN_DAYS is not the same as SCRUB_OLDER_THAN_DAYS. That said, SCRUB_OLDER_THAN_DAYS should probably be in the plugin as well. When I created that part of the plugin, I was following advice from a user since I am not a user of this plugin.
Ok I've said I'm no master here and got a bit lost reading through the script, but thinking about - I'd assume the SCRUB_OLDER_THAN_DAYS variable is probably just a populated 1 or 0 to start the scrub process. I'd imagine setting SCRUB_FREQUENCY_IN_DAYS is used somewhere to allow a check at the end of the DIFF/SYNC run to say - what's the counter at compared to SCRUB_FREQUENCY setting? If SCRUB_OLDER=1, then run SCRUB, if SCRUB_OLDER=0, then don't scrub and increment counter. From a logic standpoint, that would make sense to me.
Just my guess though here on how that variable may be used.
-- On a side note, @ryecoaaron - it seems the counter is back to incrementing by 1 now. I think there may be something in there somewhere when manual Sync is run, it's causing the counter somewhere to be tripped or something is being read from somewhere else relevant to the last successful SYNC job. My manual interventions may have been causing that number to appear incremented by 2, as for the last couple days I had some issues requiring me to address and run manual SYNC jobs, which I think were one each AM after seeing my report. I might finally be on a solid track though of working successfully with "Everything OK" outputs at the end. I'll keep monitoring and advise if there arises and further issue. Thanks again for all your help and educated guessing, since you don't use the plugin 
By manual run, are you running the script by manually executing the scheduled job? Or are you running a sync from the plugin?
By manual run, are you running the script by manually executing the scheduled job? Or are you running a sync from the plugin?
Running sync from the plugin, no report output though, so I never saw the increment of the counter. I did run the scheduled job manually to test the increment yesterday (2 in a row, increased report output by 1). Last night, scheduled job ran and increased by 1 only. I could attempt running a manual sync through the plugin today and seeing the output tomorrow to see if we end up with a +1 or +2 increment if that would be helpful? Or I could even run a manual SYNC through the plugin, then run the scheduled task and see if it does +1 or +2?
Manual sync from the plugin shouldn't increment the counter. All it does is execute the snapraid sync command.
Hello,
thanks for the great plugin!
In the aviation-industry, we use a lights-out philosophy. Imagine a Aircraft-Cockpit. How do you -with these thousands of dials and switches figure out if everything is ok?
No Light = OK
Light = Warning
I think, this should be the same with omv.
But currently, the snapraid-diff script is very Verbose.
I get:
Warnings about 'Ignoring mount point' are possibly due to AUFS or mhddfs-Pooling in OMV
SnapRAID DIFF started - Sa 28. Jan 00:00:01 CET 2017
Loading state from /media/7c15d186-8611-4520-85a5-2c3f1e1ff58b/snapraid.content...
Comparing...
WARNING! Ignoring special 'socket' file '/media/678c601d-8d2e-4be0-9226-d20a6f772f8b/Backups/omv_backup/omvbackup/var/agentx/master'
(and hundrets more)
98%, 22005 MB, 153 MB/s, CPU 7%, 0:00 ETA
99%, 22134 MB, 152 MB/s, CPU 6%, 0:00 ETA
100% completed, 22147 MB accessed in 0:02
Big1_Data 40% | ***********************
Big2_Data 36% | *********************
Big3_Data 0% |
parity 16% | *********
raid 2% | *
hash 2% | *
sched 1% |
misc 0% |
|___________________________________________________________
wait time (total, less is better)
Everything OK
Saving state to /media/7c15d186-8611-4520-85a5-2c3f1e1ff58b/snapraid.content...
Saving state to /media/678c601d-8d2e-4be0-9226-d20a6f772f8b/snapraid.content...
Saving state to /media/a0fa3926-4100-4740-a2ca-11f7cc46fee1/snapraid.content...
Saving state to /media/1e9433cd-993d-4af7-9114-fb761bccdbbf/snapraid.content...
Verifying /media/7c15d186-8611-4520-85a5-2c3f1e1ff58b/snapraid.content...
Verifying /media/678c601d-8d2e-4be0-9226-d20a6f772f8b/snapraid.content...
Verifying /media/a0fa3926-4100-4740-a2ca-11f7cc46fee1/snapraid.content...
Verifying /media/1e9433cd-993d-4af7-9114-fb761bccdbbf/snapraid.content...
SnapRAID SYNC Job finished - Sa 28. Jan 00:04:38 CET 2017
----------------------------------------
SnapRAID SCRUB-Cycle count (7) not met (5). No scrub was run. - Sa 28. Jan 00:04:38 CET 2017
Yours, SnapRAID-diff script
Do you deem this useful?
Why not saving this output to disk and just send the output if *not* Everything is OK?
Greetings,
Hendrik
Both parameters exist in the script. So, SCRUB_FREQUENCY_IN_DAYS is not the same as SCRUB_OLDER_THAN_DAYS. That said, SCRUB_OLDER_THAN_DAYS should probably be in the plugin as well. When I created that part of the plugin, I was following advice from a user since I am not a user of this plugin.
After getting a better look at the script, this is correct. The "older_than" variable is for the "-o" option passed to the scrub command. This option will tell scrub to only scrub files older than "n" number of days. Not a big deal if it's set to zero, it will potentially scrub them all. The scrub frequency determines how often it performs a scrub, and that part is working. Possibly in the future we can have a spot to set the "older_than" variable in the plugin.
Getting this error email when its running a scheduled diff, using latest snapraid.
/usr/sbin/omv-snapraid-diff: line 365: [: too many argumentsHas something changed from ver 10??
Getting this error email when its running a scheduled diff, using latest snapraid.
Code/usr/sbin/omv-snapraid-diff: line 365: [: too many argumentsHas something changed from ver 10??
Same here. I created a thread about it but maybe better to keep it here.?!
/usr/sbin/omv-snapraid-diff: line 365: [: too many argumentsI had this same error and found that my snapraid diff was definitely failing.
Try ssh into the box and going to /usr/sbin and running "sudo omv-snapraid-diff".
Mine failed with an error writing to a content file due to a read-only file system (my cause was a faulty SATA cable causing one of the content filesystems to be locked read-only - fixed by replacing the cable and fsck).
Another way to see if the diff is failing is checking "/var/log/snapraid.log". If you see 'Added: [] - Deleted: [] - Moved: [] - Copied: [] - Updated: []' instead of something like 'Added: [0] - Deleted: [0] - Moved: [0] - Copied: [0] - Updated: [0]', the diff is definitely failing so the script cannot parse the output correctly.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!