Beiträge von Sean

Thanks - much appreciated!

Ah, I see. If the same settings are applied to each method, it could be problematic to have "v" as a default parameter.

Zitat von ryecoaaron

I added fsarchiver to the plugin three years ago and the verbose flag has always been there. And it only uses one 'v' which is the least amount of verbosity. You are the first to ask for less info.

OK then, two's company...

I also don't need to know every single file that has been backed up every week. Like "Trottel", I would prefer just getting the info if everything went well or if there were problems (so I don't want to disable the email notification completely). But I keep an archive of my mails, so I would prefer shorter mails.

Would it be possible to move the "v" option into the backup -> settings tab? It could still be default, I would just like to be able to switch it off.

OK, it worked now. I'm down to 70% usage now; let's hope that the size of the logfiles becomes smaller over time. (I just wonder why syncing helped hulmul...)

Thanks again for your help!

You guessed right, it was an initial run (after OMV reinstallation). Thanks for this! I run it manually, about once per month, so it shouldn't be a permanent problem.

However, I'm still wondering why the ramdisk is still full after syncing, and what I can do to ensure that the ramdisk is synced (and purged) more frequently and regularly. Any hints?

Here's the content of /var/log:

-rw-r--r--   1 root    root                  3456 Aug 18 12:20 alternatives.log
drwxr-xr-x   2 root    root                   100 Aug 17 13:06 apt
-rw-r-----   1 root    adm                 217088 Aug 19 11:17 auth.log
-rw-r-----   1 root    adm                 269141 Aug 13 00:00 auth.log.1
-rw-r-----   1 root    adm                  11574 Aug  6 00:00 auth.log.2.gz
-rw-r--r--   1 root    root                     0 Jul 24 12:07 bootstrap.log
-rw-rw----   1 root    utmp                   768 Aug  8 15:44 btmp
drwxr-x---   2 _chrony _chrony                 40 Jul 31 11:10 chrony
drwxr-xr-x   2 root    root                   120 Aug 13 00:00 cron-apt
-rw-r-----   1 root    adm             2444763136 Aug 19 11:09 daemon.log
-rw-r-----   1 root    adm             1198425414 Aug 13 00:00 daemon.log.1
-rw-r-----   1 root    adm               49760225 Aug  6 00:00 daemon.log.2.gz
-rw-r-----   1 root    adm                   2732 Aug 18 12:20 debug
-rw-r-----   1 root    adm                   7842 Aug  9 16:33 debug.1
-rw-r-----   1 root    adm                   2221 Aug  3 11:38 debug.2.gz
-rw-r--r--   1 root    root                 54829 Aug 17 13:06 dpkg.log
-rw-r--r--   1 root    root                 32160 Aug  7 17:14 faillog
-rw-r--r--   1 root    root                     0 Jul 24 12:07 fontconfig.log
drwxr-xr-x   3 root    root                   160 Jul 31 11:07 installer
drwxr-sr-x+  3 root    systemd-journal         60 Jul 31 11:10 journal
-rw-r-----   1 root    adm                 111932 Aug 18 19:41 kern.log
-rw-r-----   1 root    adm                 330875 Aug 11 16:34 kern.log.1
-rw-r-----   1 root    adm                 163110 Aug  5 11:17 kern.log.2.gz
-rw-rw-r--   1 root    utmp                293460 Aug 19 10:02 lastlog
-rw-r-----   1 root    adm                  12288 Aug 19 08:23 mail.info
-rw-r-----   1 root    adm                  19662 Aug 11 13:03 mail.info.1
-rw-r-----   1 root    adm                  14110 Aug  3 11:03 mail.info.2.gz
-rw-r-----   1 root    adm                  12288 Aug 19 08:23 mail.log
-rw-r-----   1 root    adm                  19662 Aug 11 13:03 mail.log.1
-rw-r-----   1 root    adm                  14110 Aug  3 11:03 mail.log.2.gz
-rw-r-----   1 root    adm                 303104 Aug 19 11:17 messages
-rw-r-----   1 root    adm                 602901 Aug 12 23:17 messages.1
-rw-r-----   1 root    adm                 199783 Aug  5 23:17 messages.2.gz
-rw-r-----   1 root    adm                      0 Jul 24 12:07 monit.log
drwxr-xr-x   2 root    adm                    460 Aug 19 00:00 nginx
-rw-rw-rw-   1 root    root                  7981 Aug 19 03:01 omv-backup.log
drwxr-xr-x   2 root    root                    40 Jul 13 13:14 openmediavault
-rw-------   1 root    root                   338 Aug 18 12:20 php7.4-fpm.log
-rw-------   1 root    root                   902 Aug  9 16:33 php7.4-fpm.log.1
-rw-------   1 root    root                   367 Aug  3 11:00 php7.4-fpm.log.2.gz
drwx------   2 root    root                    40 Jul 31 11:10 private
-rw-r-----   1 root    adm                      0 Aug 14 00:00 rsync.log
-rw-r--r--   1 root    root                471289 Aug 13 11:40 rsync.log.1.gz
drwxr-xr-x   3 root    root                    60 Jul 31 11:05 runit
drwxr-xr-x   2 root    root                    80 Aug  6 00:00 salt
drwxr-x---   3 root    adm                    880 Aug 19 08:47 samba
-rw-rw-rw-   1 root    root                  1220 Aug 11 12:32 snapraid.log
-rw-r-----   1 root    adm             2445213696 Aug 19 11:17 syslog
-rw-r-----   1 root    adm             1199227538 Aug 13 00:00 syslog.1
-rw-r-----   1 root    adm               50046040 Aug  6 00:00 syslog.2.gz
-rw-r--r--   1 root    root                     0 Jul 24 12:07 tallylog
-rw-r-----   1 root    adm                  12288 Aug 19 08:23 user.log
-rw-r-----   1 root    adm                  30469 Aug 12 08:23 user.log.1
-rw-r-----   1 root    adm                  10549 Aug  5 08:19 user.log.2.gz
-rw-rw-r--   1 root    utmp                 34944 Aug 19 10:02 wtmp

syslog and daemon.log contain a lot of entries from backup jobs (USBbackup apparently enumerates every single file).

I have the same problem, but even after the sync, I still get:

Filesystem                                 Size  Used Avail Use% Mounted on
folder2ram                                 8.3G  8.3G     0 100% /var/log

When I click "sync all", it claims to sync /var/log:

will now sync all mountpoints
sync of /var/log successful!
sync of /var/tmp successful!
sync of /var/lib/openmediavault/rrd successful!
sync of /var/spool successful!
sync of /var/lib/rrdcached successful!
sync of /var/lib/monit successful!
sync of /var/cache/samba successful!

Why is the ram disk still full?

And anyway, regularly syncing manually is not a real solution IMO... Isn't there a way to make sure that the ram disk is synced reguarly?

With the "Diff script settings" header it becomes much clearer.

So I agree that the time required to change the design would be better spent on other tasks - like integrating several arrays into the main branch...

Zitat von ryecoaaron

Not sure what you mean. scrub frequency only applies to the diff script.

That's precisely what wasn't clear to me. On the settings page, it says "scrub frequency - 7 - units in days". There is no indication that this is only relevant if the diff script on the other page is activated. And I still don't understand how the "7 days" scrub frequency interacts with the scheduling settings from the diff page.

I would find it more intuitive if all settings related to the scheduled diff were on that page. (Just a suggestion)

Zitat von ryecoaaron

That should be a random uuid.

Maybe you forgot to call srand()?

Zitat

How are you going to "disable" them?

I figured changing the scrub percentage from "100" to "0" would work.

Zitat

They are used in the diff script AND manual scrub commands in the plugin.

Ah, I didn't know that. In that case, it's a bit confusing that the scrub frequency is on the settings page and the date/time is in the diff sub-page...

Zitat

Manual runs will never send emails but you do have to have notifications setup for the script if/when it gets fixed.

Good to know.

OK, it's been a while, but now I have installed the new system with two Snapraid arrays. Manual snapraid sync and check jobs work fine so far (without rebuilding the cache, the errors really seem to result from the old system).

BTW, in the new OMV installation, the config file for the first array is called omv-snapraid-114a88d2-53ed-11ed-8eee-b3f2573b9c38.conf again, so it was no accident that it was the same for both of us.

Now I have three remaining questions:

- If I were to to run scheduled tasks using the config files for the different arrays, as in

snapraid -c /etc/snapraid/omv-snapraid-114a88d2-53ed-11ed-8eee-b3f2573b9c38.conf sync ,

this should work, right?

- About the "scrub" configuration in the "Snapraid settings": Should I disable them also (as with the scheduled diff)?

- The "send mail" checkbox in the settings is checked, but I haven't received any mails after the manual syncs / checks. Do I have to do something else? I have setup my mail account in "System Notification"

Maybe I figured something out. My network controller's id is "enp3s0", but in /etc/network/interfaces ist was "enp2s0" (probably because there was only one SATA adapter during installation).

I changed /etc/network/interfaces, and at first glance, it seems to work.

Do I have to worry that the file will be overwritten the next time I change the configuration and press "apply"?

There haven't been any BIOS updates for this board yet.

yes. It says:

r8169 110592 0

installed kernel 6.2.16-4, rebooted -> network is unreachable.

OK, I have received the parts now, and just out of curiosity, I tried to install the standard OMV6-distribution, and it went smoothly. The components are:

- ASRock N100M motherboard

- 16GB Crucial RAM

- 500GB Samsung M2 SSD for the OS

- Syba SI-PEX40064 4 Port SATA III Controller

- 5x Western Digital Ultrastar DC HC550 18TB

- 400W be quiet Power Supply

My troubles began when I added the second Syba controller and the 5 HGST 8TB disks from the old system: The disks were detected, but the network became "unreachable". I suspected a driver issue with the kernel, so I installed the backports kernel, I now have "6.1.0-0.deb11.7-amd64", which is the newest one available for bullseye (if I'm not mistaken). The problem persisted.

I played around a bit with the configuration, even suspected a power issue because the system worked when both controllers were connected, but some of the disks were not connected to the PSU. (But that wasn't it, when I connected all drives to the PSU but removed one of the controllers, it also worked.) It also works if both controllers are inserted, but some SATA ports are not connected.

I have a suspicion that one of the two controllers might be faulty, but I haven't been able to make sure of it, and before I buy a new one (or switch to an 8x LSI controller as Aaron suggested) I want to make sure that there is no other issue I'm not seeing yet.

In any case, losing the network after connecting an HDD seems weird to me.

Yes. And I didn't generate that file manually.

I figured that was the default for the first array... And it is the only one in /etc/snapraid.

Hmm, I started a "snapraid check" job (with the config file you mentioned), and it crashed the system after a few hours.

Then I tried a "snapraid sync" (also with the new config file), and it crashed during/after reading the ".content" file

In both cases, the whole system became unresponsive (while still permanently accessing disks). Is that normal? IMO, snapraid might crash if there is an error somewhere, but it should take the whole system down...

I'm thinking whether I should rebuild the whole parity disk...

Zitat von ryecoaaron

How are you running them?

Like this: