I found out why my backup took 3 hours and sometimes a few minutes.
1 - I was copying everything each time, so I was losing the benefits of rsync.
2 - I have a backup of my entire environment on the same disk every two days, at almost the same time, so the two backups were running simultaneously. One was 140 GB and the other was 6.7 GB, but with lots of small files.
To have versioning in my backups, I added a post-backup script to do an mv jellyfin jellyfin.1
The problem with my script was that I was losing the benefit of rsync, especially on a large number of small files that hardly ever change. So I modified my script to do a cp -r jellyfin jellyfin.1
This should solve my problem, but it doesn't explain why one day the backup took 1 minute and the next day it took 3 hours.
I should point out that in my configuration, each backup is a complete backup of the directory. Not just a copy of the files that have been modified.
Ok, let me know what you find. The script shouldn't stop on a bad file.
Hi,
It's strange, yesterday the backup took about 1 minute, this morning it took 3 hours. And yet the scheduled Jellyfin optimization tasks are running fine every day just before the backup.
And the two backups are the same size when compared with du -sh.
It seems that the various optimizations to Jellyfin have solved the problem.
Thank you for your help, and sorry for the “false” bug.
I programmed my server to shut down at night to save energy. And since the problem seems to be coming from the Jellyfin data, I went digging through the settings and found that some scheduled tasks, such as cache cleaning and database optimization, hadn't been performed in months. I'm going to restart these tasks and change their schedule, and we'll see if that fixes things.
In the backup script?
For the moment, I suspect some specific file or my backup disk.
Not in your script
The compose plugin's backup script is just running an rsync. Nothing fancy. https://github.com/OpenMediaVa…n/omv-compose-backup#L343
I had already seen this information and suspect there is another problem. Thank you for your help.
I wanted to restart the task to send you the logs. Except that I just noticed that everything is going well, no errors, just copying a 6 GB folder takes almost 3 hours between 1 SSD and 1 HDD internally.
I'm going to run some tests to see if I have the same problem when doing a simple copy or if it's due to the backup plugin.
Hi,
Occasionally, my scheduled Docker backup task crashes, and I don't understand why. I find my containers stopped and my backup incomplete
After hours of research, I had found people who had stability problems with the r8169 version of the various realtek in the kernel so I had resolved to stay in DHCP (because the problem was solved).
But last week I saw a firmware-realtek update in OMV
firmware-realtek:amd64 (20241210-1~bpo12+1, 20250410-2~bpo12+1)
And having switched back to IP static to test, it seems that the problem has been solved with this update.
I hope there won't be any more problems
After hours of research, I had found people who had stability problems with the r8169 version of the various realtek in the kernel so I had resolved to stay in DHCP (because the problem was solved).
But last week I saw a firmware-realtek update in OMV
firmware-realtek:amd64 (20241210-1~bpo12+1, 20250410-2~bpo12+1)
And having switched back to IP static to test, it seems that the problem has been solved with this update.
I hope there won't be any more problems
Hello everyone,
My main network card is a pcie card 2.5 Gb : https://www.amazon.fr/dp/B0CF1…t_b_fed_asin_title_1&th=1
I have a 2.5 switch between my router and my server : https://www.amazon.fr/dp/B0C64…t_b_fed_asin_title_1&th=1
I have a problem with my server, sometimes, when exiting standby, it seems that the physical network link is not completely up and reconfiguring the network cards when exiting standby causes me to lose my default route.
There is no problem with DHCP.
root@nas:~# journalctl --since "2025-05-14 08:00:00" --until "2025-05-14 08:05:00" | grep enp7s0
mai 14 08:00:11 nas kernel: r8169 0000:07:00.0 enp7s0: Link is Down
mai 14 08:00:11 nas kernel: r8169 0000:07:00.0 enp7s0: Link is Down
mai 14 08:00:11 nas kernel: r8169 0000:07:00.0 enp7s0: Link is Up - 2.5Gbps/Full - flow control rx/tx
mai 14 08:00:10 nas systemd-networkd[531]: enp7s0: Lost carrier
mai 14 08:00:10 nas avahi-daemon[775]: Withdrawing address record for 192.168.10.10 on enp7s0.
mai 14 08:00:10 nas systemd-networkd[531]: enp7s0: Gained carrier
mai 14 08:00:10 nas avahi-daemon[775]: Leaving mDNS multicast group on interface enp7s0.IPv4 with address 192.168.10.10.
mai 14 08:00:10 nas avahi-daemon[775]: Interface enp7s0.IPv4 no longer relevant for mDNS.
mai 14 08:00:11 nas systemd-networkd[531]: enp7s0: Could not set route: Nexthop has invalid gateway. Le réseau n'est pas accessible
mai 14 08:00:11 nas systemd-networkd[531]: enp7s0: Failed
mai 14 08:00:11 nas avahi-daemon[775]: Joining mDNS multicast group on interface enp7s0.IPv4 with address 192.168.10.10.
mai 14 08:00:11 nas avahi-daemon[775]: New relevant interface enp7s0.IPv4 for mDNS.
mai 14 08:00:11 nas avahi-daemon[775]: Registering new address record for 192.168.10.10 on enp7s0.IPv4.
mai 14 08:00:17 nas autoshutdown[3245501]: root: INFO: '_get_network_details(): 'enp7s0' has IPv4 address: 192.168.10.10, IPv6 address: N/A'
mai 14 08:00:17 nas autoshutdown[3245501]: root: INFO: '_check_ul_dl_rate(): Running on interface: enp7s0'I can confirm there is no connection with autoshutdown-plugin. The problem appears randomly after resuming. I will try to check my switch and my network card.
EDIT : editing the /etc/default/networking file is useless, it doesn't work.
I Will try a fix proposed by chatGPT :
nano /etc/systemd/system/fix-network-after-resume.service
[Unit]
Description=Reconfigure enp7s0 after resume
After=suspend.target
Wants=network-online.target
[Service]
Type=oneshot
ExecStart=/bin/bash -c "sleep 5 && networkctl reconfigure enp7s0"
[Install]
WantedBy=suspend.targetNo one has any idea ???
please delete the atached files and change passwords.
Thank you very much, I didn't know that the check put the .env information in plain text.
This should be fixed in 7.4.5 in the repo now.
It works successfully ! Thank you !
Ok thanks for the explanation.
If you need any further information or testing, don't hesitate to ask here.
Waiting for a patch, I thank you for your help and all your work in this community around openmediavault.
When you obfuscate paths and uuids, it just makes it harder to tell what the script is doing. Trying to figure out what is wrong.
Can you post the output of the Check button on the Files tab for this compose file?
Hello,
I have 2 redis volumes for nextcloud and onlyoffice that don't save to a compose stack. The plugin detects a comment # SKIP_BACKUP therefore the skip but no such comment is present. Moreover, even when adding # BACKUP, the backup skips the volume.
Attached: the stack compose and the output of the backup
